Store shapes
Picking KV, document, relational, and log stores by access pattern — not fashion.
Store shapes
Business constraint
New feature needs user profiles, activity feed, and idempotent webhook intake. Team debates "one database for everything."
Naive v0
Stuff all shapes into one relational DB (or one document store) without modeling query patterns or retention.
Failure drill
Feed queries scan huge tables. Webhook dedupe contends on hot rows. Profile reads pay for write-heavy indexes they never use. Migrations become archaeology.
Evolution path
Iteration 1
Map each use case to access: point lookup, range by time, transactional multi-row, append-only audit.
Iteration 2
Split: profiles → KV/row store; feed → time-partitioned append or fanout tables; webhooks → idempotency key store with TTL.
Iteration 3
Define ownership boundaries and sync (events vs dual write). Prefer explicit outbox over silent dual writes.
Implementation cut
Write a one-page store matrix before schema. Reject "we already have Postgres" as a complete answer without query sketches.
Numbers
p95 latency per access pattern. Storage growth per stream. Cross-store consistency lag SLO if async.
Pattern tags
Self-check
- What access pattern forces a log shape?
- When is a document store a poor fit?
- How does shard key vs time bite feeds?
- What belongs in an idempotency store?
- Why document ownership boundaries?
Walkthrough
Recordings will appear here when published. Until then, work the failure drill and lab locally — pause after each iteration and write the metric that moved.