Data Model Design

Design the data model before sketching endpoints — storage layout constrains every API choice downstream.

How It Works

Data model design is the bridge between requirements and API endpoints. Before choosing REST methods and shapes, define entities (users, posts, orders), their relationships (one-to-many, many-to-many), and access patterns (read-heavy vs write-heavy, point lookups vs range queries). Key decisions: normalization vs denormalization (normalized data is cleaner but requires joins; denormalized is faster to read but expensive to update consistently), primary-key strategy (auto-increment vs UUID vs hash), and indexing (which columns based on expected query patterns). In interviews, always sketch 3–5 core tables with primary keys and foreign keys before drawing boxes for services — APIs should follow from the data model, not the other way around.

Real-World Example

Instagram's data model uses a denormalized Media table where each post stores author_id, content, timestamp, and common counters (likes_count, comments_count) directly as columns rather than computing them from joins. This denormalization is deliberate: reading a post doesn't require joining against a separate counts table, making the read path ~10× faster. The trade-off is careful atomic updates on the counters when likes and comments arrive — but since reads dwarf writes for social-media feeds, the asymmetry is worth it.