Articles
Aerospike Interview Questions: Partitions, Replication, and Consistency Modes
Prepare Aerospike interview answers on partition routing, replication factor, AP and SC read modes, ambiguous writes, and failure-specific recovery.
An Aerospike interview answer should identify the namespace's consistency mode, the operation's policy, and the surviving copies of the affected partition. “It is replicated” does not settle whether a read can be stale, whether a write can proceed, or what a timeout means.
Evidence boundary: official Aerospike documentation supplies the product facts below. Failure timelines, capacity calculations, and interview recommendations are original exercises and inference. No candidate reports establish a particular employer's interview format or question frequency. This is a database-mechanics guide, separate from a company hiring guide.
Follow a key from the client to a partition
Question: “Does the client send every request through one coordinator?”
Official fact: Aerospike's data-distribution documentation describes 4,096 logical partitions per namespace and deterministic record assignment. Partition ownership is distributed across nodes; there is no single database-wide master. The master designation belongs to a partition copy.
Original exercise: imagine six nodes and record K in partition P. P's master is node A and its replica is node D. The client needs a current partition map to route the operation to the appropriate owner. Node B can be healthy and reachable without holding an eligible copy of P.
If A leaves, the interesting question is how ownership and the client's map change, and whether a usable surviving copy exists. Do not answer merely that “the load balancer sends it to another node.” Aerospike-aware routing is a different contract from sending arbitrary requests to a generic healthy backend.
Inference: when diagnosing intermittent failures after a membership change, compare the affected keys' partition placement, client topology refresh behavior, and migration state. If failures concentrate on a subset of partitions, aggregate node CPU is unlikely to explain the whole incident.
The number 4,096 is not a promise that every partition has equal request traffic. Hash distribution can spread distinct keys while one extremely popular key still creates concentrated work. Explain whether the symptom is uneven record placement, a hot record, or an overloaded replica before changing cluster size.
What does replication factor two actually mean?
Question: “With RF2, do we have the master plus two backups?”
Official fact: RF2 means two total copies: one master and one additional replica. RF1 means one copy. This definition is part of the partition replication model.
Original arithmetic: a namespace has 600 GB of logical record data and RF2. A first approximation is 1,200 GB across copies, before indexes, storage overhead, temporary migration copies, headroom, and compression effects. Dividing by six yields 200 GB per node only under a balanced steady-state assumption. It is not a complete sizing recommendation.
Now remove one node. The remaining five nodes need room and throughput for recovery. If each was provisioned exactly at its comfortable steady-state limit, “automatic rebalancing” cannot manufacture spare capacity. A good answer separates the replication guarantee from the operational resources needed to reestablish it.
Inference: ask about rack or failure-domain placement. Two copies on machines sharing a failure domain do not protect against losing that domain. Conversely, a surviving majority of nodes does not prove that a particular record has any surviving copy. Draw the copies for the record you are discussing.
Why are AP and SC namespace choices different?
Question: “Is Aerospike eventually consistent or strongly consistent?”
Official fact: the consistency-mode documentation distinguishes AP namespaces from SC namespaces. The answer depends on namespace configuration and read settings, rather than one global label applied to every deployment.
Original failure exercise: six nodes split into groups of four and two. Record K's two copies happen to be A in the larger group and D in the smaller group. The interviewer asks whether both groups can update K and later merge the updates.
For an AP discussion, explain the possibility of divergent versions and the configured conflict-resolution behavior after healing. An application-level reconciliation requirement may remain: selecting one database version is not equivalent to combining two business actions.
For an SC discussion, explain that partitions may become unavailable rather than serve operations that violate the selected consistency contract. Do not promise that the larger group always owns every answer or that every minority operation always fails. Partition state, roster, surviving copies, and the operation policy are necessary inputs.
Inference: two concurrent updates saying “balance becomes 90” and “balance becomes 80” cannot be reconciled into a reliable accounting history by choosing the highest generation alone. If the domain requires both debit events to be preserved, design the authoritative operation and its transactional boundary explicitly.
An interview answer gets stronger when it states which failure outcome the business can accept: rejection with retry, a stale display read, or potentially conflicting writes. “Availability is better” has no meaning without identifying what response remains valid.
SESSION is not the same as LINEARIZE
Question: “An SC namespace exists, so every read is globally linearizable, correct?”
Official fact: Aerospike's policy documentation distinguishes SC read modes, including SESSION, LINEARIZE, ALLOW_REPLICA, and ALLOW_UNAVAILABLE. The relaxed modes trade stronger guarantees for access to additional copies or otherwise unavailable partitions. Verify the exact enum names and defaults in the SDK version you use.
Original decision matrix:
| Requirement | Read-policy direction | What to explain |
|---|---|---|
| Preserve the documented session ordering contract | SESSION | Define the scope of the session guarantee |
| Require global real-time ordering for the read | LINEARIZE | Stronger ordering can require more coordination |
| Read an eligible replica with relaxed guarantees | ALLOW_REPLICA | A reachable copy need not hold the latest value |
| Accept potentially stale data from an unavailable partition | ALLOW_UNAVAILABLE | Explicitly bound where such results are safe |
This table is a reasoning aid, not a deployment configuration. A policy cannot turn an AP namespace into an SC namespace. A strong namespace also does not make a deliberately relaxed read equivalent to the strongest read mode.
Inference: an account settings page may tolerate a short-lived stale label. A read used to approve an irreversible financial operation has a different requirement. Choose the guarantee from the operation's correctness needs, then verify its cost and failure behavior on the actual deployment.
Avoid saying “read any replica for lower latency” without checking policy interactions. Rack preference and replica-selection settings do not override every SC read contract. The relevant SDK documentation and server configuration determine which options actually affect a request.
Can a reachable cluster still have an unavailable partition?
Official fact: the strong-consistency guide documents partition-unavailability outcomes and the assumptions behind its guarantees. It also identifies the editions supporting SC. Do not extend those guarantees to arbitrary combinations of erased storage, repeated failures, or unsupported operating conditions.
Original copy ledger:
| Time | P on A | P on D | What the application knows |
|---|---|---|---|
| T0 | Current master copy | Current replica copy | Two copies exist |
| T1 | A fails | Surviving copy | Recovery depends on partition state |
| T2 | Still absent | D fails before replacement is established | No reachable copy in this simplified ledger |
| T3 | Other nodes respond to health checks | Still absent | Cluster reachability does not supply P's data |
This deliberately simplified example does not predict every SC transition. Its purpose is to expose a bad premise: four healthy unrelated nodes are not four copies of K. To answer an actual incident, inspect the server's partition state and whether migrations completed before the second failure.
Inference: useful monitoring includes unavailable partitions, migration progress, client errors by result code, and the application's timeout rate. CPU, memory, and node count remain useful, but they cannot substitute for the record-specific availability evidence.
Does a write timeout mean nothing was stored?
Question: “The client timed out during an increment. Can it safely retry?”
Not from the timeout alone. The request might never have arrived, might have been applied before its response was lost, or might have reached a stage whose outcome requires reconciliation.
Official fact: the client consistency concepts explain the interaction between write acknowledgment, replica propagation, and operation behavior. A client-observed error is not a universal proof that no state changed.
Original timeline: A receives increment visits by 1. It processes the operation, but the client loses the response. The client retries the same arithmetic operation. If the retry is processed as another increment, the count can move by two. Increasing the timeout cannot retroactively identify the first attempt's outcome.
Inference: distinguish idempotent replacement from repeated non-idempotent mutation. Even replacement is only business-idempotent when replaying the same value cannot overwrite a later legitimate change. A generation check, stable operation identifier, or transaction may help, but each must be connected to a precise invariant.
A verification read also needs the right contract. Reading a stale replica and seeing the old count does not prove that the first write failed. Name the read policy, the operation identifier if one exists, and the reconciliation procedure before claiming the retry is safe.
Does SC make two-record transfers atomic?
Question: “We debit one record and credit another in an SC namespace. Is that a transaction?”
SC configuration and multi-record atomicity are separate questions. Two independently successful record operations can leave a partial business action if the process fails between them.
Official fact: current transaction documentation covers multi-record transactions; the client documentation specifies Aerospike Server 8.0+ on an SC namespace for that capability. “Aerospike supports only single-record transactions” is therefore an outdated blanket answer.
Original reasoning: for a transfer, define whether both balances, the operation record, and any deduplication marker participate in the same supported transaction. An email notification sent afterward is not automatically part of it. If a compatible transaction API is unavailable in the stated environment, explain the alternative recovery model rather than silently assuming one.
Inference: verify server release, edition, namespace mode, SDK support, and transaction limits before choosing a design. SC roster administration also has an explicit procedure in the configuration guide; changing membership safely is more than toggling a boolean during an incident.