Wrap-up and resources
Key Takeaways
- 1. Scaling and load balancing: Estimate with numbers before you design. Keep app servers stateless so you can add as many as you like behind a load balancer, and move state to a shared database or cache.
- 2. Caching, replication and sharding: Cache what is read often and changes rarely, spread reads across replicas, and only shard the database once the simpler fixes run out.
- 3. Microservices and queues: Start with a modular monolith, and split only when the team or the load forces it. Every queue consumer must cope with the same message arriving twice.
Glossary
| Term | Definition | Part |
|---|---|---|
| Vertical scaling | A bigger server. Simple, with a ceiling. | 1 |
| Horizontal scaling | More servers behind a balancer. | 1 |
| Stateless | The server keeps nothing between requests. | 1 |
| Cache-aside | The app reads the cache; on a miss it reads the DB and fills it. | 2 |
| Replication lag | The time between a write on the primary and it reaching replicas. | 2 |
| Sharding | Spreading data across several databases by a key. | 2 |
| Modular monolith | One app with internal modules that have clear boundaries. | 3 |
| Idempotent | Repeating the operation does not change the result after the first time. | 3 |
| DLQ | A queue for messages that failed every attempt. | 3 |
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Official docs3
Articles2
Done with this lesson?
Sign in to save your progress.