NoSQL · Data models beyond tables
What are NoSQL best practices in production?
Short answer
Design from access patterns, bound document and partition growth, choose high-cardinality keys, validate with realistic data, monitor tail latency and rehearse failure, backup and migration paths.
Good NoSQL practice is mostly discipline before launch and observability after it. The database gives you fewer guardrails than a relational engine, so the application and the design process have to supply them.
Design and data
- List access patterns and their volume before choosing keys
- Keep partitions and documents bounded; split data that grows forever
- Use high-cardinality keys and test for skew with realistic tenants
- Duplicate deliberately for reads, with an owner and a repair path for each copy
- Add schema validation or application-level contracts for critical collections
Operations
- Monitor p99 latency, errors, replication lag, disk and compaction, not just averages
- Test backups by restoring into an isolated environment
- Use expand-migrate-contract for schema changes and keep them resumable
- Apply least privilege, TLS, encryption and audit logging
- Load-test with production-like data and failure injection before launch
Document the trade-offs in the design itself. A future engineer needs to know why a field is duplicated, why a key was chosen, and which query a table exists to serve. That context is what prevents a well-meaning change from breaking the access pattern.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which practice prevents the most production surprises?
- 2How do you document a NoSQL data model for a team?
- 3Why is production-like data important for load testing?
- 4What should trigger a review of the data model?
Say it in the interview
I treat NoSQL design as a set of explicit trade-offs. I start from access patterns, keep partitions and documents bounded, use high-cardinality keys and test for skew. Duplication is fine when it has an owner and a repair path. Operationally I monitor tail latency and replication lag, test restores, and use expand-migrate-contract for changes. I also document why each key and duplication exists, because the next engineer needs that context to avoid breaking the access pattern.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.