1.6 KiB
AI summary:
- System design is not about memorising architecture patterns; it is about knowing why each component is needed.
- Start with real numbers first, such as traffic, read/write ratio, latency, and throughput, before drawing the design.
- Every component, like caching, sharding, or replication, only helps under certain conditions.
- Good designers think through failure cases, such as database crashes, cache delays, or datacentre splits.
- The best approach is to start simple, measure the system, and only add complexity when a clear metric proves it is needed.
Article Notes
sharding or replication.
Sharding is the process of splitting a database into smaller, more manageable pieces called shards. Each shard is a separate database that contains a subset of the data. Replication, on the other hand, is the process of copying data from one database to another. This can be done for backup purposes or to improve performance by distributing read requests across multiple replicas.
Notes for page 3
This is the part that changes everything. Every component has this envelope of conditions where it actually helps. Caching works when reads dominate and access patterns cluster together. Sharding makes sense when write throughput matters way more than transactional guarantees. Replication helps when read availability beats consistency.
Notes for page 4
Start with one database, one server, no cache. Only scale when some specific metric like latency or throughput or cost crosses a threshold you can actually name. When you add a component, explain what new failure mode it introduces and how you’d even detect it.