CodeParkPin down scale, latency, availability, consistency and durability early. Each one changes the design.
Scale and read/write ratio.
- A read-heavy system pushes you toward caches, read replicas (copies of the database that serve reads) and a CDN.
- A write-heavy system pushes you toward partitioning (splitting data across machines) and append-friendly stores.
Latency targets. Teams usually state latency as a percentile. For example, "p99 under 100 ms" means 99% of requests finish in under 100 ms. A target like this rules out long chains of service calls that wait for each other. It favours precomputing results ahead of time.
Availability. A target of 99.99% uptime needs redundancy across zones (separate data centres). It also needs no single points of failure.
Consistency.
- A bank balance needs strong consistency: every read sees the latest write.
- A like counter can be eventually consistent: reads may be a little out of date for a short time. This makes it cheaper to scale.
Durability. Losing an uploaded file is unacceptable. So the system must copy each write to other machines before it tells the user the write succeeded.
Also ask about:
- data retention
- geographic distribution
- compliance (legal rules)
These decide where data is stored and for how long.
- Ask about the scale and the read/write ratio.
- Ask for the latency target, which is usually given as a percentile.
- Ask for the availability target, because it decides how much redundancy you need.
- Ask what consistency each feature needs.
- Ask about durability, data retention and geography.