🚀 Day 2 of 10: Designing Data-Intensive Applications
Your data model is not just a storage choice.
It’s the language that shapes how you think about the problem.
As Wittgenstein said: “The limits of my language mean the limits of my world.”
In software, the data model you pick defines the limits of your system.
Here’s what Chapter 2 of Designing Data-Intensive Applications really teaches:
### 1. Data models live in layers Application objects → General-purpose model (tables / JSON / graphs) → Storage engine layout → Hardware bits
Each layer hides complexity from the one above it. Choose poorly at the middle layer and everything becomes painful.
| Aspect | Relational | Document | |-----------------|-----------------------------|-----------------------------| | Structure | Flat, normalized tables | Nested trees (JSON) | | Relationships | Excellent joins (M:N) | Weak joins, heavy denorm | | Schema | Schema-on-Write | Schema-on-Read | | Best for | Complex relationships | Self-contained 1:N entities |
Document stores win when you load entire hierarchical records (like a LinkedIn profile) in one go. Relational wins when you need flexible queries across many-to-many relationships.
### 3. The object-relational mismatch is real Your domain objects are trees and graphs. Relational databases force you to shred them into flat tables. ORMs hide the pain… until performance or schema evolution bites you.
### 4. Declarative > Imperative Stop telling the database *how* to find data. Tell it *what* you want and let the query optimizer do the hard work.
SQL, Cypher, SPARQL, and Aggregation Pipelines all win because they are declarative.
### 5. When graphs become necessary If “anything can connect to anything” in your domain (social networks, recommendations, knowledge graphs), neither tables nor documents scale elegantly. Property graphs + Cypher (or SPARQL/Datalog) become the natural fit.
Architectural rule of thumb: - Mostly self-contained trees? → Document - Lots of joins and M:N relationships? → Relational - Dense, multi-hop connections? → Graph
Most real systems end up with polyglot persistence - using the right model for each access pattern.