Recipes

How each piece works

One concept per recipe. Each explains the problem, the approach, and the trade-offs, and links to the real code that does it. The backend recipes come first; the client- ones then take a single concept across all three mobile apps side by side.

idempotent, oversell-proof reservations in Go

A concert goes on sale. Ten thousand people want the hundred VIP seats, and a good number of them double-click the buy button because the page felt slow. Two failures are lurking:

a distributed lock in Redis

The backend runs as several stateless replicas (see the scale recipe). An in-process mutex only serialises goroutines within one replica; it does nothing about two replicas touchin

proving no overselling under load

Every backend in this lab claims it cannot oversell. A unit test with fake adapters argues it; the Go and TypeScript tests even fire hundreds of goroutines/promises at an in-memory

horizontal scale without overselling

One backend instance can only serve so many requests, and a sale's whole problem is a traffic spike. The obvious fix is to run more instances behind a load balancer. But the moment

a virtual waiting room

When a sale opens, the arrival rate dwarfs both the seat count and the system's safe throughput. Letting everyone hit the reservation path at once means contention, timeouts, and a

asynchronous payment via a message broker

Charging a payment provider is slow (network, their processing) and flaky (they have bad days). If POST /orders waits for the charge to complete, every checkout holds a request ope

JWT access tokens with refresh rotation

A ticketing session outlives any single request, but a long-lived credential is a liability: if it leaks, the attacker has it until it expires. You want tokens short enough that a

rate limiting (two layers)

A sale opening is indistinguishable from a denial-of-service attack: a huge burst of requests, some from real buyers, some from scripts trying to grab stock. Left unchecked, the bu

HTTP caching with ETag and Cache-Control

When a sale opens, thousands of clients poll the event list and event detail. Most of the time nothing has changed, but every poll still costs a full response — bandwidth on the wi

circuit breaker, retry, and timeout on the payment path (Go)

Payment goes through an external provider, and external providers have bad days. If the provider gets slow, every payment worker blocks on it and the backlog grows until the whole

distributed tracing with OpenTelemetry (Go)

RED metrics at the gateway tell you POST /reservations got slow. They do not tell you why — was it the Redis lock, the Postgres decrement, or the handler itself? When a request fan

RED metrics at the gateway

Seven backends in five languages. Instrumenting each one for metrics means seven different client libraries, seven ways to name a counter, and seven chances to measure the same thi

mutual TLS between the gateway and the backend

TLS at the edge protects traffic between the browser and the gateway. But inside the cluster, the gateway-to-backend hop is often plain HTTP on a "trusted" network — and "trusted n

security in every layer

Security is not a feature you add; it is a property of every layer, and a single missing control is the one an attacker uses. A ticketing sale handles credentials, money, and a sca

test against an external HTTPS URL with a tunnel

Applies to every client: the web SPA and all three mobile apps.

the injected base URL (and a reachability probe that can't hang)