Weak on data modelling
Targeted path for engineers whose designs are strong on compute and weak on storage. Covers how to pick the right store and partition it right.
For: Engineers whose feedback often cites "data model unclear" or "why that database?"
After this path
Pick the right store, the right partition key, and the right indexes for a given prompt — with defensible reasoning.
- 1Skill
Data model design
Entities, relationships, keys, normalization vs denormalization.
Why this, here: Nail the entity model before you touch storage. Junior candidates skip this; seniors don't.
- 2Skill
Storage choice justification
Picking SQL vs KV vs doc vs blob vs timeseries based on access patterns.
Why this, here: Match access pattern to storage shape — not defaults, not "we use Postgres".
- 3Skill
Sharding & partitioning
Partition key selection, hot spots, rebalancing, consistent hashing.
Why this, here: The single most consequential decision in a distributed data design.
Checkpoint
Stop and defend: pick a partition key for a messaging app’s messages table and say what breaks if you partition by sender_id versus conversation_id. If both sound fine, the choice isn’t load-bearing yet — re-read hot partitions.
- 4Deep dive
Indexing strategies
B-tree, LSM, inverted, compound, and geo indexes tied back to access patterns.
Why this, here: The indexes decide your read latency. B-tree vs LSM vs inverted is a first-principles choice.
- 5Skill
Consistency trade-offs
Strong vs eventual vs causal, quorum, read-your-writes.
Why this, here: Ties the storage choices back to the business-level consistency requirements.