AdvancedDistributed Systems

Lab: reason about distribution

Apply CAP, consistency, idempotency, caching, and failure handling to scenarios.

Lab · optionalFundamentalsAdvanced10 min

Recommended first

By the end of this lesson you will be able to:

Optional scenario lab. Distributed systems are hard because the network is unreliable. Practice reasoning about the trade-offs that forces.

1.
During a network partition (nodes can't reach each other), a distributed data store must sacrifice:
Nothing — you can have it allEither consistency or availabilityBoth consistency and availabilityOnly latency
2.
A "charge the card" request might be retried after a timeout (you can't tell if the first one landed). To stay safe, the operation should be:
FastIdempotentCachedEncrypted
3.
Users report the page "shows the wrong value, but only sometimes." Prime suspect?
A typo in the codeA stale cacheThe compilerTheir keyboard
4.
A dependency is down. Without which safeguard can a call to it hang and exhaust your resources?
A timeoutA commentA faster CPUMore logging

Assume the network fails, make retried operations idempotent, suspect the cache, and bound every wait.

Finished reading? Mark it complete to track your progress.

Designing for failure

In a distributed system, components will fail. Build so the whole survives.

Measure before you scale

Find the real bottleneck with data — don't optimise or scale on a hunch.