Aerospike Application Logic and Data Migration: Ensuring Rollback Safety During Bin Evolution

Aerospike employs a schema-less architecture where record structures are defined at the application layer rather than the server level. When evolving data models, developers often implement an "Expand and Contract" pattern to transition from an old bin to a new bin without downtime.

A critical challenge arises during the transition phase where the application must maintain backward compatibility to allow for a safe rollback. If the application logic is reverted to a previous version, it must be able to retrieve the most current state of the data, even if that data was written to a new bin by the failed deployment.

The uncertainty lies in managing the consistency of these dual-written bins and the eventual cleanup of orphan bins without impacting performance or risking data loss during a version revert.

• What is the recommended strategy for ensuring read-consistency when rolling back application logic to a version that is unaware of newly created bins?
• How should orphan bins be handled to prevent storage bloat while maintaining a safe rollback window?