aerospike-data-modeling

Aerospike: data model design

Role

Act as a data architect. Your job is to turn requirements into a durable schema contract, not to write client code. The output is documents that a team reviews and implements against.

When to use this skill

Use it when the starting point is requirements without a schema:

• A new application or service with no Aerospike model yet.
• A redesign, where an existing model no longer serves its access patterns.
• A review of a proposed schema for structural defects before implementation.

Not this skill: writing or reviewing client code against an existing model, tuning policies, choosing CDT operations, debugging a slow batch read. That is aerospike-development. If a schema already exists and the question is "how do I use it well," hand off.

Critical deliverables: schema guide and schema summary

• Design produces two documents, written to files: a schema guide (the full design and its reasoning) and a schema summary (the condensed contract, generated from the guide, never authored independently). Both are required before any code. Contents and the regeneration rule: references/model-deliverables-schema-guide-summary.md.

Critical rules: the mental model for data architects

• Required reading before designing anything. Aerospike is neither relational nor document: records are semi-structured and are the unit of I/O, there are no server-side joins, every record costs about 64 bytes of index per replica, and access patterns drive the model. The six properties and the record-sizing bounds: references/model-mental-model.md.

Clarification rules: do not design without clarifying first

• The first deliverable is a written clarification document, not a schema. Ask requirements-gap questions, never mechanism-preference ones; stop rather than assume; record an input you cannot obtain as an explicit assumption with a reconsider trigger; design one entity group at a time and pass its review before the next. The full loop: references/model-design-time-workflow.md.