Demos and exercises#
Work through one module at a time: change the inputs, inspect what responds, and connect the result to your own project. Repeat a scenario until you can explain the trade-off without relying on the interface. Where practice is available, switch to its tab to check your understanding. Saved results are shared with the chapter exercises.
For a small local implementation with your own model, download the local exercise workspace. Set up once, choose CSV, test quality, persisted retries or HTTP caching, and run that exercise’s independent checks.
- Modules
- 16
- Exercises
- 13
- Mode
- Self-guided
Reading investigations
Use these alongside the main chapters. Predict a result, change one condition and explain what the evidence supports.
Scalable development
Deterministic boundary labDeterministic boundary lab
Limit the agent to valid transitions
TESTS_PASS is a supplied event in this executable statechart.
This demo runs no application tests; a real workflow must verify test
evidence before supplying that event.
Pause & think
Follow the release gates
In this delivery statechart, release readiness requires both passing checks and an approved review. Checks have passed, but review has not started. Select the missing gate and the destination of REQUEST_CHANGES during review.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Passing checks alone does not complete the parallel verification state. Review must also approve. REQUEST_CHANGES returns the patch to implementation.
Architecture
Cache decision labHTTP cache lab
Where does the next response come from?
Every case begins after one successful response. Change its policy and age,
then trace the next request without changing the URL. For an executed
browser observation, try the optional
local practice workspace
and choose http-cache/README.md.
Architecture
Web architecture lensWeb architecture lens
What crosses the boundary after an action?
The first document may be rendered on the server, built ahead of time, or assembled in the browser. That is a separate choice from the later update below. All three examples start from the same loaded activity page.
Full-document navigation
- Response
- Replacement scope
Draft outside the activity list
A fragment or client render can also discard state if it replaces the draft's owner. In your project, inspect one real action in DevTools: method, status, content type, replaced DOM region and draft behavior. Make one bounded update with your model, then verify the saved event and draft separately.
Benchmarking
Tail latency simulatorTail latency simulator
An average can hide slow requests
Pause & think
Calculate the average and the tail
A fixed sample contains 20 requests: 18 take 40 ms each and two take 240 ms each. Use the nearest-rank percentile: sort the values, then take rank ceil(0.95 × 20). The objective requires latency strictly below 120 ms. Calculate the mean and p95, then choose which meet the objective. This sample is separate from the adjustable simulation in Explore.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
The total is 18 × 40 + 2 × 240 = 1200 ms, so the mean is 60 ms. Rank 19 is 240 ms. The average meets the objective while p95 does not; an average can conceal a slow minority.
Benchmarking
Browser performance workbenchBrowser performance workbench
Compare two browser update strategies
02 / Inspect the runs
Elapsed time including frame waits
Run the same interaction five times to reveal its distribution.
- Median total
- —
- Fastest
- —
- Slowest
- —
- Longest JS slice (median)
- —
Five runs show variation in this browser. Frame callbacks are a scheduling proxy, not proof of pixel presentation; slices exclude later layout and rendering.
Benchmarking
OpenTelemetry trace explorerOpenTelemetry trace explorer
Follow one request, span by span
The rows cover one server's handling of an inbound HTTP request. Browser work and time outside this server span are excluded. Select a row to inspect the record the SDK could include in a batched OTLP export.
Server trace
POST /events · 286 ms on server
4bf92f3577b34da6a3ce929d0e0e4736
Select any span row to inspect its telemetry record.
Try this in your project: instrument one operation, record a normal request and a deliberately delayed or failed attempt, then inspect the exported spans. Preserve the request result and explain what a missing span would prevent you from concluding. The records above are authored examples.
Agent fleets
Sequential work boundAmdahl’s Law · S(N) = 1 / ((1 − p) + p/N)
Find the limit of parallel work
- Ideal speedup
- 2.50×
- Relative time
- 40.0%
- Efficiency
- 62.5%
- Speedup limit
- 5.00×
Four agents divide the parallel work, but the sequential 20% remains.
Pause & think
Does a faster feature mean more accepted work?
Before calculating, predict whether doubling a fleet from four to eight agents will double accepted output, and explain your prediction.
Each feature needs 80 minutes of implementation with one agent and 20 minutes of review by one person. The agents work together on one feature, divide implementation time perfectly, and start the next feature as soon as implementation ends. Review of earlier features can overlap that implementation. Assume no coordination cost, continuous work, every feature passes review, and no withdrawal.
Calculate completion time for an isolated feature with no queue ahead, then production and review rates for the eight-agent fleet. Use ongoing rates, not counts in the first clock hour. Finally, calculate unfinished-work growth and assess the effect of doubling the fleet.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
With four agents, an isolated feature takes 80/4 + 20 = 40 minutes; with eight, it takes 80/8 + 20 = 30 minutes. These correspond to ideal Amdahl speedups of 100/40 = 2.5 and 100/30 ≈ 3.33 for the fixed task. During continuous work, four agents finish implementation every 20 minutes, producing three candidates/hour; eight finish every 10 minutes, producing six. One reviewer can accept at most 60/20 = three features/hour. With eight agents, unfinished work therefore grows by 6 − 3 = three features/hour. Doubling the fleet finishes an isolated feature sooner but leaves accepted throughput unchanged. Later features wait longer as the review backlog grows, so 30 minutes does not describe every feature in that stream. Explain which assumption you would investigate before recommending more agents, and what evidence would justify changing review capacity or admission.
Scaling
Saturation boundary labCapacity limit lab
Find the first binding limit
A steady-rate model with one visit per stage, successful work and one buffer before the pipeline. Completion is the minimum of admitted load and all declared capacities. Admission limiting rejects excess immediately; without it the buffer grows. Bars compare admitted rate with limits, not measured stage utilization. There are no latency, transient queue or production capacity predictions.
Pause & think
Locate the next capacity limit
Each request visits every stage once. Capacities are API 180, database 110, workers 150, and downstream 130 requests/s. Offered load is 150 requests/s, with no retries. Use the smallest stage capacity as the throughput ceiling. Then raise database capacity to 150 requests/s, leaving all other capacities unchanged.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Initially the database limits throughput to 110 requests/s. Increasing its capacity moves the limit to the downstream stage at 130 requests/s. Offered load still exceeds capacity by 20 requests/s.
Scaling
Latency budget mapLatency budget lab
Count distance and database waits
Optional depth
Explore a specific mechanism when it helps answer your question. These models and appendix activities do not add required submissions.
Architecture
ACID transaction labACID transaction lab
Keep state and history consistent
Predict the stored state and client result, then reveal an authored trace. These examples execute no database operations. Transaction scope, the concurrent program and acknowledgement timing answer different questions.
This is a deterministic transaction model, not a benchmark of a particular
database. Real isolation and durability depend on the database, transaction
boundaries, constraints, storage configuration, and failure model. For
actual atomic rollback and process-restart records, try the optional
course workspace
(persisted-retry/). It does not reproduce the isolation-level
comparison.
Appendix D: Agent-system security
Fleet trace debuggerFleet trace debugger
Match fleet activity to resource costs
Fixed synthetic teaching packet. No models or tools execute in this demo.
Appendix E: Scalability models
Reliability chain labLusser’s Law · Rworkflow = ∏ri
See how step reliability compounds
- Per-step completion
- 99.500%
- Correct completion
- 60.6%
- Safe stop
- 0.0%
- Wrong result
- 39.4%
At 99.500% per step, 100 independent critical steps complete correctly 60.6% of the time.
Appendix E: Scalability models
Contention curve labUniversal Scalability Law · C(N)
See when more workers reduce throughput
- Selected capacity
- 5.57×
- Best displayed concurrency
- 22
- Best displayed capacity
- 7.33×
- Next worker
- helps
At eight workers, added concurrency still increases modeled capacity.
Scaling
Orchestration control loopBrowser cluster lab · Webernetes
Watch controllers restore the desired state
Debrief the mechanism and its limits
Roll out v2, send requests, then roll back and repeat. Name the desired state, the observed state, and the controller action after each experiment. Then identify what remains outside this model.
- Replicas add service instances; they do not remove database limits.
- Replacement demonstrates recovery, not uninterrupted availability.
- This simulator omits real images, resource limits, persistent volumes, and production networking.
Appendix F: Durable workflows
Durable effect retry labDurable retry orientation
See when a retry duplicates an effect
Browser simulation: counts and ledgers below are held in memory. No worker process crashes and no durable storage is written. Predict the effect count, stop at the missing-completion boundary, then recover.
For actual process loss and persisted records, use
persisted-retry/ in the
course workspace. Compare
worker attempts/completions with receiver effects/receipts, including the
fresh-key negative control.
Appendix C: Advanced web boundaries
CAP partition labCAP partition lab
Compare write policies during a partition
Helsinki becomes isolated from the Frankfurt–Dublin majority. Alice and Bob then try to start the same work item from opposite sides of the split.
The model holds workload, topology, and failure constant so the policy is visible. The write-invariant check alone does not establish linearizability for all reads and writes. Real systems also define quorums, timeouts, leases, and conflict resolution.
Apply the ideas · 9 exercises
More practice
Connect the calculations, choose a fair comparison, and separate observations from explanations. Check your answers here or continue in the chapter.
Pause & think
Follow work from events to review
A stable event pipeline completes 20 events/s with average end-to-end time 0.5 s. A stable development workflow accepts four changes/hour with average time from submission to acceptance of three hours. Both times include waiting inside their respective boundaries. Calculate the average work in progress implied by Little's Law for each. Then suppose submissions rise to six changes/hour while acceptance stays at four, with no discarded changes. Can the earlier steady-state calculation describe this growing backlog indefinitely?
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
The event calculation is 20 × 0.5 = 10 events. The development calculation is 4 × 3 = 12 changes. The same relationship applies to different work when boundaries, windows, and units agree. After the increase, unfinished changes accumulate at two/hour, so the earlier stable calculation cannot describe the backlog indefinitely. Check arrival/completion balance and waiting time again. Neither calculation identifies the cause of delay or proves the waiting time is acceptable.
Pause & think
Choose the question before the equation
You have two questions. First, a stable event pipeline completes 40 events/s with average time 0.25 s inside one declared boundary: what average work in progress is consistent with those observations? Second, a fixed development task has an 80% parallelizable share and a 20% sequential share: what is the ideal speedup with four workers and no added coordination cost? Choose a law for each question, then calculate its result.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Little's Law answers the flow-consistency question: 40 × 0.25 = 10 events. Amdahl's Law answers the fixed-workload speedup question: 1 / (0.2 + 0.8/4) = 2.5. Matching averages do not identify a bottleneck or prove acceptable latency. Ideal speedup does not guarantee accepted-change throughput: integration overhead, variable tasks, and correctness can change the result. Explain which measurement or assumption you would check before recommending more workers.
Pause & think
Check whether the averages agree
At one declared boundary you observe L = 25 operations, λ = 40 operations/s, and W = 0.25 s. Calculate λW, then select the conclusion supported by these three values alone.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
λW is 10, not 25. Check compatible boundaries, observation windows, units, omitted waiting, and whether arrivals and completions balance. The discrepancy alone does not locate a bottleneck or show that adding workers will help.
Pause & think
Choose a valid comparison
You want to test whether batching improves useful write throughput while keeping p95 end-to-end latency below 100 ms and errors at or below 0.1%. Select the comparison that isolates batching. Then evaluate a run with higher throughput, p95 = 90 ms, and errors = 0.8% against those declared criteria.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Keep the workload, dataset, environment, and acceptance criteria comparable while changing batching. A run with p95 = 90 ms passes the latency bound, but 0.8% errors violates the 0.1% error bound. Higher throughput does not compensate for failing a declared acceptance criterion.
Pause & think
Check a scaling contract
A service must handle 200 requests/s while keeping p95 below 150 ms and errors at or below 1%. A run handles 220 requests/s with p95 = 180 ms and errors = 0.5%. Check the run against this contract.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Throughput and errors pass, but latency fails. Handling more requests is insufficient when the declared quality bound is violated.
Pause & think
Separate response from outcome
An API commits an event to storage, then the network loses its response. The browser times out. Use only these stated facts to classify the outcome.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
The storage commit happened even though the browser received no confirmation. A timeout describes what the caller observed; it does not undo or disprove the commit.
Pause & think
Calculate the whole change cycle
A change passes through four sequential stages with no overlap: clarification 10 minutes, editing 10, checks 15, and review 25. A tool halves editing time; every other stage stays unchanged. Calculate the new total and the time saved.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
The original cycle takes 60 minutes. Editing falls from 10 to 5 minutes, so the new cycle takes 55 minutes and saves 5 minutes. A local speedup affects only its share of the full cycle.
Pause & think
The status is unchanged. Is the operation idempotent?
Before choosing, predict whether an unchanged final status is enough to make an operation idempotent. Write a brief reason naming the effects you would inspect.
A work item starts in progress with no completion activity event. Its completion contract promises to set the status to Done and record exactly one activity event for that transition. The first attempt commits both, but its response is lost. A retry on another instance leaves the status at Done and appends a second completion activity event. Both commits are durable, and there is no deduplication.
Count the stored completion activity events, assess the whole operation against its contract, and select the mechanism that would prevent the duplicate event for retries of this logical command.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
There are two completion activity events. The status assignment is idempotent in isolation, but the whole operation is not: its promised effect includes exactly one activity event for the transition. Idempotency is this property of the intended effect, rather than the name of a retry mechanism. One implementation reuses a stable command key and atomically enforces that key while recording the state change, activity event, and reusable result in authoritative storage. A retry then returns the recorded outcome without appending another event. A per-instance cache cannot coordinate retries routed elsewhere, and a longer timeout cannot guarantee that a response arrives. The caller's uncertainty does not change the stored facts given in this scenario. Explain why a transaction that commits both writes together still needs a rule for repeated commands.
Pause & think
Classify evidence and next steps
Use observation for a reported measurement, inference for an explanation drawn from evidence, and proposal for an action to try. Classify each statement by its role; you are not being asked whether the explanation is true.
Automatically checked practice. Saved answers are private to your account.
Preview the exercise context for the assistant
This prepares an editable message. Review it in the assistant before sending. Your notebook notes are not included.
Checking saved answers…
Your answers to earlier versions
Show worked answer
Measurements describe what was recorded. A causal explanation goes beyond that observation. A proposed experiment states what to do next and can test the explanation.