Is this a video course?

No. This is an interactive, slide-based learning platform. Each lesson has rich text, animated diagrams, live code editors, and quizzes. You learn by reading, interacting, and doing, not by watching videos passively.

How long do I have access?

Forever. Both pricing tiers are one-time payments with lifetime access. This includes all current 766 lessons and any future content we add.

What level of experience do I need?

None. We start from absolute basics like 'What is latency?' and build up to distributed consensus protocols. The Foundation level assumes zero prior knowledge of system design.

How much does the system design course cost?

7.99 US dollars for lifetime access globally, or 499 Indian rupees for lifetime access in India. One-time payment, no subscription, no hidden fees. 11 lessons are free with no signup required.

What technologies are covered?

Everything from DNS and load balancers to Kubernetes, Kafka, distributed databases, consensus protocols, stream processing, security architecture, and observability. We cover principles and real-world implementations used at Netflix, Google, Amazon, Uber, Stripe, and more.

Is this useful for system design interview preparation?

Yes. The lessons are structured around the exact topics asked in system design interviews at FAANG and top-tier companies. Interactive diagrams help you practice whiteboard-style explanations. Covers everything from URL shortener design to distributed payment systems.

How is this different from ByteByteGo or Educative?

766 interactive lessons (4x more than most competitors), 16 different diagram types that build step by step, real production examples from Netflix, Google, Amazon, Uber, and Stripe, and lifetime access for a one-time payment of $7.99 instead of annual subscriptions costing 100 to 200 dollars per year.

What is durable execution for an AI agent?

Durable execution is a promise that a run's progress is saved as it happens, so a crash costs you only the current step and nothing before it. It uses a disposable worker, an append-only event history log that records the result of every completed step, and an engine that schedules, retries, and can suspend the run, with all durable state in the log rather than the worker's memory.

Why does an agent run need different recovery than a web request?

A web request lives for milliseconds and touches little, so if it fails you retry the whole request cheaply and correctly. An agent run lives for minutes or hours, makes many external calls, may pause for a human, and has steps that change the world in ways you cannot take back, so the retry unit can no longer be the whole run and you need to resume from where you stopped without repeating a side effect.

What is an idempotency key and why does a durable run need one?

An idempotency key is a stable identifier for a specific side effect, derived from the run and the step, that lets the engine check whether an action already happened before firing it again. A durable run needs it because retrying a step that charged a card would charge it twice, so the key ensures a side effect happens exactly once no matter how many times the step is attempted, the same pattern payment APIs like Stripe use.

What are the costs of durable execution?

Durable execution has three costs: you must write the run as a deterministic workflow whose steps can be recorded and replayed, you must operate an event history store with an extra durable write per step, and you must handle versioning, because deploying new code while a run is paused can make the replay diverge from the recorded history. Because of this it is not worth it for a short read-only run that is safe to retry from the top.

What tools implement durable execution?

The pattern predates agents in workflow engines like Temporal and Uber's Cadence, whose core rule is that workflow code must be deterministic so it can be replayed while non-deterministic work is pushed into recorded activities. Agent frameworks like LangGraph adopt the same idea through checkpointers that persist state so a run can be interrupted and resumed, and the idempotency-key half is the mechanism payment APIs like Stripe expose.

A durable agent run crashes at step 40. Why is re-executing the code from the start the wrong way to recover?

A model call is not deterministic, so re-running it produces a different result rather than the original step 40, and any tool it called fires a second time, Classic workflow recovery works by re-running deterministic code and trusting it to produce the same output. A model call breaks that assumption: it is non-deterministic, so re-invoking it gives a fresh, different answer instead of the recorded step 40, and every side effect it triggered, such as an email or a charge, happens again. The fix is to record each model and tool result the first time and replay the recording on recovery.

During recovery, what actually happens to the steps that already completed before the crash?

Their recorded results are read back from the log to rebuild state, without calling the model or tools again, Recovery replays the recorded results. The worker reads the results of the already-completed steps back from the durable log, in order, to rebuild the run's state up to the last completed step. No model call or tool call is repeated during replay. Only after state is rebuilt does the run make its next real call and continue live.

Why does a durable run need idempotency keys on its side effects even though it already records results?

So that retrying a step that sends an email or charges a card does not perform that action a second time, Retries are what make a step recoverable, but retrying a step that already charged a card would charge it twice. An idempotency key is a stable identifier for a specific side effect. Before firing, the engine checks whether the key was already recorded; if so it skips the call and returns the recorded result, so the effect happens exactly once no matter how many times the step is retried. This is the same pattern payment APIs like Stripe use.

Which run is the best candidate for durable execution rather than a plain retry-from-the-top?

A long run that sends emails, moves money, and pauses for a human approval partway through, Durable execution is real infrastructure with real cost: you must write the run as a deterministic workflow and operate an event history store with an extra durable write per step. A short read-only run is its own safe retry unit and does not need it. The payoff appears when a run is long, has side effects that must not repeat, or must suspend for a human, which is exactly the case where retrying from the top would double side effects or lose progress.

Durable Execution: An Agent Run Is a Workflow, Not a Request

Name: System Design Masterclass
Availability: InStock

in Agents In Production

This lesson is part of the AI Engineering course. Unlock the full course, a separate one-time payment, for lifetime access.

One-time payment. Lifetime access. No subscription.

Global

$20/lifetime

One-time payment via PayPal

Get Lifetime Access

5 Foundation lessons free, try before you buy

India Special

India

₹999/lifetime

One-time via UPI, cards, or net banking

Get Lifetime Access

5 Foundation lessons free, try before you buy

“The interactive diagrams alone are worth way more than the price.”

Anish K., Senior Engineer at a Bengaluru startup

Every ML Platform lesson, Foundation to Advanced

Real architecture diagrams with real tool logos

MLOps, LLMOps, and data engineering in depth

Quizzes with instant feedback

Built and reviewed by senior engineers

Lifetime access, all future content included

The first 5 Foundation lessons of this course are free, no payment needed. Try them now