2.2 KiB
pdf, date started, date finished, type, done
| date started | date finished | type | done | ||
|---|---|---|---|---|---|
|
2026-06-03 | 2026-06-03 | pdf-notes | true |
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
(I Thought I Knew System Design Until I Met a Google L7 Interviewer, p.2) 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.
I Thought I Knew System Design Until I Met a Google L7 Interviewer, p.2
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.
(I Thought I Knew System Design Until I Met a Google L7 Interviewer, p.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.