By now Meera's library app serves forty schools (guide 1 built it, and guide 2 followed a request through it). This guide follows one very bad school term, in which almost everything that can go wrong does. Each disaster forces one idea. (Meera, Arjun and every incident here are made up for teaching.)
The opening lesson comes from the library itself. A second desk keeps the library open when one librarian is ill. But if both desks need the key to one locked cabinet, and that key is lost, adding desks didn't solve the real problem. Software needs the same end-to-end thinking. A duplicated application still depends on its database, network, credentials, configuration and operators.
Chapter
The disaster
The idea it forces
1
"The server died during exam week"
Availability vocabulary and the fault model
2
"The principal asks: how reliable is it, really?"
SLIs, SLOs, SLAs, error budgets
3
"A whole data-centre zone lost power"
Redundancy, failover, split brain
4
"A slow recommendations service took everything down"
Timeouts, retries, circuit breakers, bulkheads
5
"One student's script requested 5,000 reports"
Rate limiting and overload
6
"Services moved, and hard-coded addresses broke"
Service discovery and service mesh
7
"A student cancelled someone else's reservation"
Authentication vs authorization
8
"The district wants one login for every school app"
OAuth, OIDC, SSO, tokens
9
"Traffic inside the data centre was unencrypted"
TLS and mTLS
10
"Someone deleted the reservations table, and the replica copied it"
Backups, RTO, RPO, storage
11
"Friday's deploy broke reservations"
Deploying, observing, cost
1. "The server died during exam week": the vocabulary of failure
The single app server's disk fails on the first day of exams. For three hours no student can reserve anything. Before fixing it, Arjun and Meera need words for what they want:
Term
Plain explanation
Availability
Can users get the required service?
Reliability
Does the system provide correct service over the relevant period?
Durability
Does accepted data survive the failures we plan for?
Resilience
Can the system absorb trouble and recover?
Fault tolerance
Can it continue despite specified failures?
Don't promise tolerance of every possible failure. State the fault model, meaning which failures you plan to survive: one instance, one disk, one availability zone, or an entire region.
At the start of term, the app looks like this:
Step 1: the smallest design that works.
You've reached the free preview of this post.
Subscribe to the Blogs plan (₹99/mo) — or use any Algomi Suite, Career, Investor, or Trader plan — to keep reading.
