Write code that stays correct when threads interleave, packets vanish, and the box you depended on dies mid-request.
Your counter is off by three and you can’t reproduce it. A test passes ninety-nine times and hangs on the hundredth. A retry charges the customer twice. These aren’t sloppy bugs — they’re what happens when more than one thing runs at once, and no amount of careful reading catches them. You start on your laptop: threads, processes, coroutines, and a race condition you cause on purpose, then fix three ways — a mutex, an atomic, and by not sharing state at all. You deadlock a bank transfer and prove lock ordering fixes it. You block an event loop and watch a service go dead. Then the machine count goes up: remote procedure calls that aren’t function calls, timeouts and exponential backoff, idempotency keys that survive a retry storm, quorum reads, Raft leader election, circuit breakers, chaos tests. Every demo ships in Go, Python, Rust, and Node.js — pick a tab, copy, run. Ten module projects, and a capstone service that stays up while you kill a node.
Built by Lakshya Kumar
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
Measure spawn cost and memory per unit yourself, then pick the abstraction that fits the workload instead of guessing.
Reproduce the bug that only shows up in production, then kill it three different ways and prove which one you need.
Stop wrapping one mutex around everything — match lock granularity to real contention and watch throughput climb.
Break the four conditions on purpose, then prove with a wait-for graph that your fix holds under real contention.
Build fan-out/fan-in pipelines that shut down cleanly, and learn the cases where shared memory still wins.
Serve thousands of concurrent requests on a single thread, with cancellation and backpressure that actually stop work.
Every remote call can hang, duplicate, or vanish — build retries, timeouts, and idempotency that survive all three.
Choose a consistency level on purpose instead of inheriting whatever your database happens to default to.
Turn a dependency outage into a degraded feature instead of a 3am page, using breakers, bulkheads, and load shedding.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Build a small service (e.g. a URL shortener or counter) that survives a node failure. Use replication, a consensus library (etcd/Raft), or a manual primary-backup setup. Prove it works with a chaos test.
Build a multi-stage producer-consumer pipeline (3 stages, each with a bounded queue) in your language of choice. Include backpressure, graceful shutdown, and a load test showing throughput is bounded by the slowest stage. Profile and identify the bottleneck.
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
I'm considering a "Concurrency & Distributed Systems" course. It covers threads, locks, channels, async/await, event loops, then moves off one machine: replication, consistency models (CAP, linearizable, eventual), consensus (Raft), fault tolerance, and chaos testing. Demos are available in Go, Python, Rust, and Node.js via code tabs. Context about me: 1. My current role/focus: [e.g. "backend dev at a 50-person startup", "self-taught, building side projects", "senior frontend engineer who wants to cross over"] 2. The hardest concurrency bug I've hit so far was: [describe it, or say "I haven't really hit one"] 3. What I'm hoping this course changes about me: [e.g. "stop being scared of multi-threaded code", "understand my team's Kafka setup", "get promoted to senior"] Answer these: - For my background, which 2 modules would have the highest immediate payoff in the next 3 months, and why? - Name a concrete failure I've probably already caused (or will soon) that this course would prevent. - Is a 30-hour investment worth it for me, or should I learn something more specific first (e.g. SQL perf, networking)? Give your honest pick and reason. - What should I explicitly NOT expect to get out of this course — e.g. Kubernetes ops, specific framework mastery?
Implement a distributed lock using Redis (or etcd) with fencing tokens. Demonstrate the classic 'GC pause' failure mode where a lock holder pauses, the lock expires, and another holder acquires it. Show that fencing tokens prevent stale-holder writes from corrupting state.
Implement Raft leader election from scratch in your language of choice. Run a 5-node cluster, partition the network in 3 ways (split brain, isolated leader, slow node), and verify the cluster converges to a single leader within the election timeout in every case.
Implement a saga for a multi-step distributed transaction (order: reserve inventory, charge payment, ship). Include compensating transactions for each failure point. Inject a failure at each step and verify the saga always converges to a consistent state.
Accessible paper summaries. Skim after Module 6 to see where the field came from.