Summary
Storage is one of the two halves of computing, and it is where most system designs either click or fall apart. Storage is just zeros and ones arranged in a useful structure — but the specific structure determines what a system can do quickly, what it can do reliably, and what it cannot do at all.
This lesson walks through why data structures are the right level of abstraction to think about storage, instead of jumping straight to specific databases. Bootcamp grads and CS students typically learn data structures in isolation (linked lists, hash maps, trees) without ever connecting them to the storage choices a real system makes. Kay closes that gap. You will see how different groupings of data structures map to different real-world storage needs — fast lookups, durable blobs, ordered queues, complex relational data — and why these groupings will later become four of the seven building blocks in the framework.
The payoff: when you see a database in a system diagram, you will start asking the right question first — "what shape of data and what shape of access," not "Postgres or MongoDB."
Key takeaways
- Storage is not a database choice. It is a data-structure choice that a database happens to implement.
- Different storage shapes (key-value, blob, queue, relational) serve different access patterns. Picking the wrong shape is the most common architectural mistake.
- Once you think in data structures, swapping Postgres for MySQL or Redis for DynamoDB becomes a trivial decision — the shape stays the same.
- The framework groups storage into four building blocks. This lesson sets up why those four are sufficient.
Storage is zeros and ones stored in a useful structure. Get the structure right and the database almost picks itself.