You know the 7 building blocks. You understand the external forces that push on a system. You have seen them in action inside Netflix. Now the question is: when you are staring at a set of requirements for a new system, how do you decide which blocks to use?
This is the decision framework. It is a set of questions, each one pointing you toward a specific building block. The goal is not to memorize a lookup table, but to develop an instinct for matching requirements to components. That instinct is what separates an engineer who builds systems from an engineer who builds features.
The Seven Questions
Each building block answers a specific type of need. Ask these questions about your requirements, and the answers will tell you what to reach for.
"Does this need to respond to a user or API request?" Use a Service. If there is a request-response cycle, there is a Service.
"Does this need to do work in the background?" Use a Worker. Transcoding video, sending email digests, generating reports. If the work can happen "later" and nobody is watching a loading spinner, a Worker does the job.
"Do I need to decouple two parts of the system?" Use a Queue. The Service that accepts a video upload should not also do the transcoding. Queues separate "accepting work" from "doing work."
"Do I need fast lookups by a known key?" Use a Key-Value Store. Session data, cached API responses, user preferences, feature flags. Think of it as a dictionary: give me the value for this exact key.
"Do I need to store and serve large files?" Use a File Store. Images, videos, PDFs, user uploads. If the data is a blob rather than structured fields, it belongs in a File Store.
"Do I need structured data with relationships between records?" Use a Relational Database. Users who have orders. Orders that contain items. If your data has relationships and you need to query across them, this is the block.
"Do I need to find similar items, not exact matches?" Use a Vector Database. "Find products similar to this one." Vector databases store embeddings and find nearest neighbors. This is the block behind recommendation engines, semantic search, and RAG systems.
The Decision Table
Here is the quick reference version. Bookmark this.
| Requirement | Building Block | Example |
|---|---|---|
| Handle user/API requests | Service | REST API, web server, GraphQL endpoint |
| Background processing | Worker | Video transcoding, report generation, ML training |
| Decouple components | Queue | Order placed > send email, upload received > start processing |
| Fast key-based lookups | Key-Value Store | Session storage, caching, feature flags |
| Store/serve large files | File Store | Images, videos, documents, static assets |
| Structured relational data | Relational Database | Users, orders, products, transactions |
| Similarity search | Vector Database | Recommendations, semantic search, RAG |
The "Start Simple" Principle
Here is the most important advice in this entire framework: 95% of MVPs need a Service and a Relational Database. That is it.
Resist the urge to add complexity before you have evidence you need it. Do not add a Queue because "what if we need to scale later." Do not add a Key-Value Store cache because "reads might be slow someday." Do not reach for a Vector Database because "AI is the future."
Start with a Service that reads and writes to a Relational Database. Build the product. Get users. Then add building blocks when you hit real problems. Slow reads? Add a Key-Value Store cache. Background jobs blocking your API? Add a Queue and Worker. File uploads? Add a File Store.
Each building block increases operational complexity. More blocks means more things that can fail, more things to monitor. Add them when the pain of not having them exceeds the cost of maintaining them.
# MVP (start here)
Service → Relational Database
# After real problems emerge
Service → Relational Database
→ Key-Value Store (caching)
→ Queue → Worker (background jobs)
→ File Store (uploads)
Common Combinations
Real systems combine blocks into recurring patterns:
- Web Application: Service + Relational Database + File Store. Every app with user accounts, structured data, and uploads.
- Processing Pipeline: Service + Queue + Worker + File Store. The Netflix pattern. Accept input, queue processing, store results.
- Cache Layer: Service + Relational Database + Key-Value Store. Database is the source of truth, Key-Value Store is the fast lane for reads.
- AI-Powered Feature: Service + Vector Database + Relational Database. Structured data in one, embeddings for semantic search in the other.
You do not need to memorize these. When you understand why each block exists, the combinations become intuitive. The external entities tell you which forces are acting on your system, and the building blocks tell you how to respond.
The AI Angle: From "Build Me an App" to Directing Architecture
This framework changes how you work with AI.
Without it, you say: "Build me a video sharing platform." The AI produces a monolith. It works for a demo. It collapses under real usage.
With the framework, you say: "Build a Service that accepts uploads and stores files in a File Store. On upload, put a message on a Queue. Build a Worker that reads from the Queue and transcodes into 3 resolutions. Build a second Service that serves the transcoded videos."
Same goal. Completely different result. You made the architectural decisions. The AI writes the implementation. Instead of describing what you want in vague terms, you specify the exact building blocks and how they connect. That is the difference between using AI and directing AI.
Where to Go From Here
That is the entire framework. Seven building blocks, three external entities, and a bias toward simplicity. It works for a todo app and it works for Netflix. The building blocks are the same. The scale is different. The thinking is identical.
If you skipped ahead, go back and build the foundation:
- What the 7 building blocks are and why they matter
- Services and Workers: the two task blocks
- Storage building blocks: the five ways to persist data
- Queues and Workers: the decoupling pattern
- External entities: the three forces shaping your system
- How Netflix works: the building blocks in action
The framework teaches you WHAT the building blocks are and WHY they matter. If you want to learn HOW to think with them through hands-on practice, interactive labs, and system design challenges, that is what the full course is built for.
But first, test your understanding. The interactive challenges let you design Instagram, Netflix, and Uber using the building blocks. No signup, no payment, just practice.