Scalable System Design & Distributed Architecture

Sharding, Replication, Event Streams & Microservice Contracts

6 modules, 30 lessons: Foundations And Estimation; Data, Storage And State; Caching, Queues And Asynchrony; Resilience And Traffic Management; Architecture And Operations; Worked Designs End To End.

Advanced · 2 hours · 30 lessons · 73 labs

Who it is for

Advanced level.

For experienced engineers, tech leads and architects who design or review backend systems: estimating load, choosing storage, caching, queues and resilience, then three designs worked end to end.

What you don't need yet:

What helps:

Before you start:

Take first:

Take next:

Learning paths:

Nobody needs to know everything before they start. Each course builds on the one before, so a learning path takes you there step by step.

Labs

73 labs, 33 of them graded: you write the code, it runs, and graded labs check the result. The outline lists each lesson's labs.

What is free

Start free: First module free with an account. Pro: Every course, lab, handbook, practice exam and certificate.

Course outline

Foundations And Estimation

  1. What A Design Is For, And How To Run A Design Discussion (3 labs): You can explain what a system design is actually for, run a forty five minute design discussion in the right order, and record a decision together with the option you rejected and the cost you accepted.
  2. Requirements: The Constraints That Shape The System (2 labs): You can separate functional requirements from the non-functional constraints that actually shape a system, turn an availability target into a monthly downtime budget, and show why availability multiplies along a chain of hard dependencies.
  3. Back Of The Envelope Estimation: Traffic And Throughput (2 labs): You can turn a user count into mean and peak queries a second, apply a peak factor and a read to write ratio, convert throughput into a server count, and state every assumption you used out loud.
  4. Back Of The Envelope Estimation: Storage And Bandwidth (3 labs): You can estimate stored bytes from a row size, a write rate and a retention window, apply index and replication multipliers, size shards from the result, and convert read traffic into egress bandwidth.
  5. Latency Numbers Every Engineer Should Know (4 labs): You can recite the latency numbers that matter, compose a request budget from them, explain why the speed of light sets a floor no engineering removes, and show how fan out turns a good tail latency into a bad user experience.

Data, Storage And State

  1. The Storage Decision: Relational Versus Document (2 labs): You can choose between relational and document storage from access patterns, transaction boundaries, and change ownership, while naming the failure mode your choice creates.
  2. The Storage Decision: Key Value, Search And Blob (2 labs): You can match exact lookup, text retrieval, and large immutable bytes to key value, search, and blob storage, while preserving a clear source of truth.
  3. Replication, Failover And Leader Election (1 lab): You can choose a replication shape, route reads and writes around a leader, and explain the recovery cost and failure mode each replica introduces.
  4. Partitioning, Sharding And Hot Keys (1 lab): You can partition state by a stable key, estimate the limits of one shard, and recognise hot keys before they turn a balanced fleet into one overloaded machine.
  5. Consistency, And The Truth About CAP (1 lab): You can describe consistency as a client visible guarantee, state CAP correctly during a partition, and choose where a product may trade freshness for availability.
  6. Eventual Consistency And What It Costs A Product (1 lab): You can model an eventual consistency race, identify the product cost of stale state, and add read routing or reconciliation where the user cannot tolerate surprise.

Caching, Queues And Asynchrony

  1. Caching Strategies And Topology (4 labs): You can place a cache at the right layer, choose a read and write strategy while naming what it costs, and size the origin for the miss rate instead of the hit ratio.
  2. Cache Invalidation And The Three Hard Cases (4 labs): You can tell expiry apart from invalidation, recognise the stampede, the stale read after write and the mass expiry in a running system, and apply single flight, versioned keys and jittered time to live to each.
  3. Queues, Events And Asynchronous Work (5 labs): You can decide what belongs on the request path and what belongs behind a queue, name the parts of a queue and what each one protects, and use Little's law to tell a buffering queue apart from a failing one.
  4. The Difference Between A Queue And A Log (4 labs): You can say what a queue and a log each guarantee, choose between them from whether the message is a command or a fact, and explain why retention and consumer lag become design inputs once you pick a log.
  5. Idempotency, And Exactly Once As A Fiction (2 labs): You can make retries harmless with idempotency keys, distinguish deduplication from exactly once delivery, and place the durable record at the correct boundary.

Resilience And Traffic Management

  1. Load Balancing And The Failure Modes It Introduces (3 labs): You can choose a balancing algorithm and a health check policy on evidence, say what layer four and layer seven each can see, and name the failure modes the balancer itself adds to the system.
  2. Timeouts, And Avoiding Cascaded Failure (1 lab): You can budget timeouts from a request deadline, propagate the remaining budget across hops, and prevent a slow dependency from consuming every worker.
  3. Retries, Backoff And Jitter (1 lab): You can retry only safe failures, apply bounded exponential backoff with jitter, and show why synchronized retries become a second outage.
  4. Circuit Breakers (1 lab): You can use a circuit breaker to stop repeated work against a failing dependency, choose a safe probe policy, and explain the degraded behavior it exposes.
  5. Backpressure And Load Shedding (1 lab): You can bound work in flight, shed low value load before queues exhaust resources, and explain why admission control is kinder than late timeouts.

Architecture And Operations

  1. Monolith Versus Services: The Honest Trade Offs (2 labs): You can argue the monolith and services decision from data ownership and team boundaries rather than fashion, price a split in latency and availability, and recognise a distributed monolith before you ship one.
  2. Observability As A Design Input (5 labs): You can decide at design time what a system must emit, choose labels that respect cardinality, record latency as a histogram rather than a mean, and turn a service level objective into an error budget with a burn rate.
  3. Capacity Planning As A Design Input (5 labs): You can explain why a queueing system is never run near saturation, size pools with Little's law, plan for peak plus the loss of one failure domain, and say what autoscaling cannot do for you.

Worked Designs End To End

  1. Worked Design One: Ticket Booking, Correctness First (3 labs): You can design a ticket booking system that sells each seat exactly once, starting from written requirements and a spike estimate rather than a diagram, choosing relational storage for the multi row transaction, and guarding the seat row with either a row lock or a version column.
  2. Worked Design One: Scaling The Ticket Booking System (3 labs): You can size the opening minute of a ticket sale, choose admission control as the design rather than an add on, partition by event while admitting the hot shard it creates, and say exactly what the waiting room costs the people standing in it.
  3. Worked Design Two: A Global Chat System (4 labs): You can design a chat system from written requirements and a connection estimate, route a message through a gateway registry to a partitioned store, order a conversation with a per conversation sequence instead of a clock, and make a client resend harmless with an idempotency key.
  4. Worked Design Two: Scaling Chat Fan Out (1 lab): You can scale the chat design with connection gateways, per conversation partitions, offline inboxes, and bounded fan out while naming the consistency cost.
  5. Worked Design Three: A Metrics Ingestion Pipeline (1 lab): You can design a metrics ingestion path from agents to durable partitions, choose retention and query stores, and preserve samples when consumers fall behind.
  6. Worked Design Three: Scaling The Metrics Pipeline (1 lab): You can scale metrics ingestion with tenant quotas, partition-aware consumers, hot label controls, and backpressure while stating the final system trade-off.

Certification courses