System Design & Architecture

1. Clients, APIs and contracts

Every distributed system is held together by the contracts between its parts: the client assumes something about the server's responses, the server assumes something about the client's requests, and both assumptions are written down somewhere — in code, in a schema, or only in someone's head. This lesson covers contract design (resources, versioning, pagination, errors), the communication styles available (request/response, events, streaming) and how to choose, consistency expectations clients must hold, and the organisational reality that API design is team design. A good contract lets two teams — or two versions of one team — work without asking each other anything.

2. Choosing where data lives

There is no "the database" — there are workloads, and there are stores built for them: transactional rows, documents, key-value speed, analytical scans, search indexes, blobs. This lesson covers the spectrum (relational, document, key-value, time-series, search, object storage), how to choose from the *shape of your access patterns* rather than fashion, partitioning and sharding when one machine stops being enough, replication for read scale and durability, and the migration discipline of changing a store under traffic. Choosing well is mostly refusing to generalise: name the queries first, then the store.

3. Caches, queues and eventual work

Two of the most powerful tools in a system are also the two most misunderstood: caches (which make reads fast by *lying slightly*) and queues (which make systems robust by *not answering immediately*). This lesson covers cache placement and the invalidation problem in its several concrete forms, cache-aside and friends, thundering herds and their remedies, queue semantics (at-most/at-least/exactly once), idempotent consumers, backpressure and dead-lettering, and the events that tie them together. Both tools trade a simple truth for performance or resilience — and both fail in characteristic, nameable ways.

1. Designing for failure

Everything you depend on fails: machines, networks, disks, dependencies, your own deploy — and often in ways that compound (a retry storm against an already-struggling service). This lesson covers the vocabulary of reliability (availability math, SLOs, error budgets), failure domains and blast radius, timeouts, retries with backoff and jitter, circuit breakers, bulkheads, graceful degradation, and the chaos discipline of testing failure on purpose. Designing for failure is not pessimism; it is the difference between an incident and an outage.

2. Authentication, authorisation and the obvious holes

Security failures are rarely exotic: they are the obvious hole somebody walked past — the missing ownership check, the token that never expires, the session cookie without HttpOnly, the secret in the client bundle. This lesson is the systems view of the two words from the backend course: identity across services, sessions and tokens at scale, permission models, the OWASP-shaped list of the most common holes with their fixes, secrets management, and the culture that keeps a system defended — threat modelling you actually run, layered defences, and the human layer. The theme is unglamorous and true: security is the boring checklist done every time.

3. Trade-offs, and writing them down

Architecture is the practice of choosing between options that each *work* — because every property you maximise costs you another, and the teams that scale are the ones whose trade-offs survive the people who made them. This lesson covers seeing trade-offs explicitly (consistency vs availability, build vs buy, monolith vs services, sync vs async), the decision records and diagrams that make choices durable, how to re-open a decision honestly when context changes, and the organisational glue — fitness functions, evolution over rewrites — that keeps a system coherent as people turn over. Nothing is free; the craft is paying deliberately and remembering why.