Skip to content
Elements of Scalable Web Development
ContentsProjectCasesDemos
Feedback overviewReview comments from across the book

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.

Modules
32
Exercises
11
Mode
Self-guided
01

Scalable development

Implementation discovery lab
Ready

Implementation discovery lab

Find a direction worth building three times

The behavior is shared. Your interpretation, stack, architecture, and experiment are yours to choose.

0/4 anchors Begin with the character of your implementation.
Interpret the common brief

Keep the required behavior, but decide what kind of product your version feels like. There is no preferred interpretation.

Need a starting point? Borrow a lens, then change anything you dislike.
Keep the common workspace capability, but choose its meaning and vocabulary: a project, room, run, campaign, class, site, or something else.
Map the required lifecycle to something concrete. It could be a task, job, case, experiment, scene, agent assignment, or repair.
Choose one user and one moment to optimize. This gives the interface a point of view without adding more required features.
Choose the technical material

Pick tools that support a learning question or a practical constraint. Familiar and unusual stacks are equally valid.

Explore a stack family These are prompts, not recommended answers.
Name the primary runtime and web framework. Normally your group keeps this family across all three builds so the AI workflow is easier to compare.
Give the system a shape

Decide where the important boundaries sit. The goal is an explainable first hypothesis, not a final architecture.

Another group must be able to run the project. Name the supported local, container, cloud, edge, or other path early.
Choose what you want to learn

A useful experiment is a question, not an extra pile of features. Keep the common core small enough that you can examine the result.

Ask something the implementation can teach you: about the stack, architecture, local model, developer experience, performance, portability, or resource use.

Your current hypothesis

Implementation direction

This is a conversation starter, not a commitment. Revise it after trying the local model and inspecting the first evidence.

Decision anchors

    Questions to discuss

      02

      Scalable development

      Constraint feedback loop
      Ready

      Constraint learning loop

      Turn evidence into project memory

      Round 1 · constrain the change Task: add CSV export to the browser event list.
      1. 01Constrainstate what must remain true
      2. 02Generateproduce a bounded candidate
      3. 03Validatecompare evidence with intent
      4. 04Revisemake the learning explicit
      5. ↩ revision constrains the next round

      Browser fixture · /events

      Three events are visible

      ● ● ● Events
      Title Location
      Architecture clinic Room 204
      Build, measure, learn Main hall
      API "office hours" Online
      Change request

      “Make the Export CSV button download exactly these visible rows.”

      Candidate boundary

      Constraints sent to the generator

      Candidate + evidence

      No candidate generated

      Round 1
      Choose the constraints the candidate should receive.
      • —Browser testCan clicking Export create a download?
      • —Changed-files checkDid the patch stay inside export.ts and export.test.ts?
      • —CSV assertionAre commas and quotation marks escaped?

      Generation is not evidence. Generate a candidate, then run the checks.

      03

      Scalable development

      Deterministic boundary lab
      Ready

      Deterministic boundary lab

      Give the agent a map

      Goal: ship a safe change The agent can choose only events enabled by the statechart.
      01

      Agentic shell

      One goal can produce different valid routes through the model.

      Current state active.planning
      Available next events
      02

      Deterministic core XState v5 + ELK

      Hierarchy shares rules; parallel regions represent simultaneous facts.

      Change delivery statechart Planning leads to implementation and parallel verification. Failed tests or requested changes return to implementation. Successful verification enables release, while cancellation can leave the active hierarchy at any point. active compound state initial planning initial implementing verifying parallel state checks compound state running initial passed review compound state waiting initial reviewing approved ready released cancelled RELEASE: active.ready to released RELEASE CANCEL: active to cancelled CANCEL PLAN_APPROVED: active.planning to active.implementing PLAN_APPROVED PATCH_READY: active.implementing to active.verifying PATCH_READY TESTS_FAIL: active.verifying.checks.running to active.implementing TESTS_FAIL REQUEST_CHANGES: active.verifying.review.reviewing to active.implementing REQUEST_CHANGES both regions final: active.verifying to active.ready both regions final TESTS_PASS: active.verifying.checks.running to active.verifying.checks.passed TESTS_PASS REVIEW_START: active.verifying.review.waiting to active.verifying.review.reviewing REVIEW_START APPROVE: active.verifying.review.reviewing to active.verifying.review.approved APPROVE
      Active configuration active.planning
      Why this matters

      The parent state exposes one shared cancellation rule.

      Inspect or export the executable model

      Copy the XState machine and paste it into Stately Sketch to inspect or simulate the generated diagram.

      Open Stately Sketch ↗
      Observed events
      1. No events sent yet.

      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.

      Sign in to save

      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.

      Practice in the chapter →

      04

      What does scalability mean for web development?

      Scalability dimensions lab
      Ready

      Scalability dimensions lab

      Choose what must scale first

      Pick project pressures Each axis shows its share of the maximum modeled pressure for demand, data, contributors, and change.

      Event tracker scenario

      Establish project

      A small event-oriented app records check-ins, status changes, sensor readings, or workflow events. Choose the pressures that would matter if the project succeeded.

      Growth and change pressures

      Dimension radar

      What the pressures affect

      Most affected
      -
      Stressed part
      -
      Watch for
      -

      Choose pressures to see which scalability dimension matters first.

      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.

      Sign in to save

      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.

      Practice in the chapter →

      05

      Architecture

      Boundary trace
      Ready

      Architecture boundary trace

      Trace one event request

      Trace POST /events Architecture becomes concrete when a request crosses boundaries.

      User action

      Room A Check in 09:15
      You tap "Check in"

      The browser turns that tap into a `session.checked_in` event for Room A.

      Browser sends POST /events
      type: session.checked_in entity: room-a time: 09:15

      What happens around the request?

      Request path

      Trace analysis

      Inspect boundary

        Architecture pressure

        Request path
        -
        Highest risk
        -
        Rules to implement
        -

        A local function call becomes a distributed workflow once the browser, server, network, and storage can disagree.

        Trace brief

        Boundary brief

        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.

        Sign in to save

        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.

        Practice in the chapter →

        06

        Architecture

        ACID transaction lab
        Ready

        Database invariant workbench

        Keep state and history in one truth

        Choose a failure boundary One lifecycle transition must produce exactly one activity event.

        Run the same work-item operation with application-managed writes or a database transaction. The ledger exposes which guarantee actually protects the project contract.

        Isolation applies when concurrent work shares a transaction boundary.

        1. 01 Read Inspect the current lifecycle state
        2. 02 Change state Move the item through the lifecycle
        3. 03 Append event Record the matching domain fact
        4. 04 Commit Make the accepted result durable
        W

        Work-item record

        The state returned by a fresh read.

        Item
        I42
        Stored state
        Initial
        Client result
        Not run
        E

        Activity-event ledger

        Successful transitions must appear exactly once.

        Seq Event Actor
        No activity events stored.
        T

        Execution trace

        The moment where the guarantee holds or leaks.

        1. ReadySelect a scenario and run it.
        A Atomicity
        Not exercised
        C Consistency
        Not exercised
        I Isolation
        Not exercised
        D Durability
        Not exercised
        ?
        Contract check

        Awaiting an operation

        The lifecycle state and activity ledger have not changed.

        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.

        07

        Architecture

        Cache decision lab
        Ready

        HTTP reuse control room

        Where does the next response come from?

        Fresh cache hit shared cache

        Every case begins after one successful response. Change its policy and age, then trace the next request without changing the URL.

        Choose the response profile
        Stored response policy Versioned asset
        stored fresh for 365 days timeline: 400 days
        01Browser cache
        02Shared cache
        03Origin
        Decision trace cache → response
          Response source
          Browser waits?
          Origin body bytes
          Representation used

          Architectural reading

          Reuse the fingerprinted response

          Policy rule immutable means the URL carries the version

          The trace models compliant HTTP cache behavior at a teaching scale. Real cache keys, platform overrides, authorization, request directives, and invalidation rules must be verified in the deployed path.

          08

          Architecture

          Web architecture lens
          Ready

          Two architectural decisions

          Compose a web request

          SSR × MPA delivery × interaction
          These labels answer different questions.

          SSR, ISR, and CSR describe where and when a view is produced. MPA, HDA, and SPA describe how the browser moves to later application states.

          01 Where and when is the view produced?
          02 How is the next state presented?
          /activity
          Work activity Today
          Rendered now
          • 09:15Design review
          • 10:30API implementation
          Ready to trace the interaction.
          Browser requests
          2
          Returned UI
          Complete HTML
          Update scope
          Whole document
          Local draft
          Reset
          Modeled response transfer after click
          ≈18 KB complete document

          Illustrative compressed responses. Headers and the common POST body are excluded; CSR assumes a 45 KB JavaScript bundle on a cold cache.

          6 requests · ≈54 KB responses · 3 document replacements

          What this combination means

          SSR + MPA

          Initial document
          After the POST
          Freshness pressure
          Client responsibility

          09

          Architecture

          Client activation lens
          Ready

          Browser activation cutaway

          What wakes up before the click?

          Hydration component tree

          The server returns the same useful event page in every case. Change only how browser behavior becomes available, then trace the first attempt to record an event.

          Choose the activation boundary
          /activity server HTML
          01 · header Work activity HTML
          02 · filters
          HTML
          03 · event feed
          1. 09:15 Design review
          2. 10:30 API implementation
          HTML
          04 · record form
          HTML
          05 · analytics
          HTML

          The document is visible. Inspect which behavior arrived with it.

          Network and execution trace Before interaction
            Initial application JS
            ≈54 KB
            Work before interaction
            Replay 5 regions
            JS at first action
            0 KB
            State crossing boundary
            Initial props snapshot

            Architectural reading

            Replay the application

            Pressure moved to initial client work

            Illustrative compressed JavaScript values for one teaching model. They show where work moves; they do not rank frameworks.

            10

            Architecture

            API contract lens
            Ready

            Contract topology lab

            Where does the client learn what it can do?

            Resource HTTP address + representation

            Hold the domain intent constant. Move between contracts to see which facts live in client code, which arrive from the server, and where change creates coordination.

            Choose the interaction style
            Fixed user intent Start work on item 42
            Required view state · title · workspace · next actions
            Wire contract HTTP exchange
            01 Client 02 Contract 03 Domain 04 Result
              Observed result Not sent yet

              Run the exchange to see what each boundary actually does.

              Knowledge ledger before the request

              C Client carries

                S Server publishes

                  Effect of requested field
                  Interaction shape
                  Discovery
                  Cache unit
                  Pressure lands on

                  Architectural reading

                  Coordinate around resources

                  Do not confuse HTTP-shaped with full REST

                  This is a structural comparison, not a ranking. Authentication, authorization, retries, observability, and versioning still apply in every mode.

                  11

                  Benchmarking

                  Tail latency simulator
                  Ready

                  Tail latency simulator

                  An average can hide slow requests

                  Choose a claim before measuring A deterministic teaching model of 60 POST /events requests. It does not contact a server.

                  01 / Define the run

                  Workload controls

                  Predict the result

                  02 / Read the distribution

                  Completion time per request

                  Typical Slow path

                  Make a prediction, then run the workload.

                  0 ms —
                  Average
                  —
                  p50
                  —
                  p95
                  —
                  Slowest
                  —

                  A benchmark should test an explicit claim. Which measurement do you expect to cross the objective?

                  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.

                  Sign in to save

                  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.

                  Practice in the chapter →

                  12

                  Benchmarking

                  Goodhart pressure test
                  Ready

                  Goodhart pressure test

                  Can your metric survive an optimizer?

                  Choose a proxy to put under pressure A deterministic two-round challenge. The values are illustrative, not observed results.
                  1. 01 Target
                  2. 02 Pressure
                  3. 03 Repair
                  01

                  Write the target contract

                  Which proxy gets rewarded?

                  Choose one optimization target
                  Intended outcome

                  Choose a proxy to reveal the result it is supposed to represent.

                  Predict what target pressure will do

                  Optimizer dashboard

                  Waiting for a target

                  UNPRESSURED
                  Targeted proxy
                  —

                  — → ?

                  Intended outcome
                  —

                  — → ?

                  Counter-signal
                  —

                  — → ?

                  Displaced cost
                  —

                  — → ?

                  Optimizer trace

                  No behavior to inspect yet. Select a proxy, predict the result, and apply pressure.

                  02

                  The number won. The outcome lost.

                  Close the gaming path

                  Observed optimizer response

                  Choose a revised gate

                  Challenge debrief

                  Outcome
                  Proxy
                  Gaming path
                  Counterevidence
                  13

                  Benchmarking

                  Browser performance workbench
                  Ready

                  Browser performance workbench

                  Repeat one interaction before trusting it

                  Ready for five local runs Measurements come from this browser and this device. No data leaves the page.

                  01 / Define the workload

                  Event-list interaction

                  Update strategy

                  Predict first: which strategy has the shorter total time, and which has the shorter uninterrupted slice?

                  02 / Inspect the runs

                  Time until the next painted frame

                  Local evidence

                  Run the same interaction five times to reveal its distribution.

                  Median total
                  —
                  Fastest
                  —
                  Slowest
                  —
                  Median longest slice
                  —

                  One run is an observation. Repeated runs show whether that observation was typical.

                  14

                  Benchmarking

                  Queue balance lab
                  Ready

                  Little’s Law · L = λW

                  Check whether the queue tells one story

                  Measurements agree

                  01 / Define the observation window

                  10 = 20 × 0.5 expected work in progress = arrival rate × time in system
                  Expected L
                  10.0
                  Observed L
                  10
                  Gap
                  0.0

                  The three averages are mutually consistent for a stable observation window.

                  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.

                  Sign in to save

                  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.

                  Practice in the chapter →

                  15

                  Appendix A: Agent workflow evaluation

                  Model evaluation lab
                  Ready

                  Challenge eval lab

                  Compare two model attempts on the same task

                  Score the attempts The result is local to this task set, not a universal model ranking.

                  Start with one task from the work you actually do in Challenge. The eval is only meaningful if the task represents your real project work.

                  Input context

                  Both models receive the same context, task, and required output shape.

                  Rubric

                  Use the same rubric for both pasted outputs.

                    Paste and score attempts

                    Run the shared prompt with two models, paste each output, then score against the rubric. Use samples only when demonstrating the workflow.

                    Compare the local result

                    Add deterministic checks where possible, then report a narrow claim about this task set.

                    Local conclusion

                    Score both attempts to see what this tiny eval can and cannot claim.

                    Comparison

                    Model Quality Checks Latency Cost
                    16

                    Benchmarking

                    Observability signal picker
                    Ready

                    Observability signal picker

                    Choose evidence for one symptom

                    Pick a symptom Your goal is not to collect everything. Choose signals that answer your operational question.

                    Which signals would let you explain why summaries are behind?

                    Candidate signals

                    What the selected signals answer

                    17

                    Benchmarking

                    OpenTelemetry trace explorer
                    Ready

                    OpenTelemetry trace explorer

                    Follow one request, span by span

                    Slow storage path found A client-only trace simulation. No telemetry is collected, exported, or stored.
                    Applicationstarts + ends spans → OTel SDKbatches span records → Collectorreceives OTLP + routes → Backendstores + explores

                    The rows below are spans from one trace. Select a row to inspect the record the SDK could include in a batched OTLP export.

                    Trace

                    POST /events · 286 ms

                    4bf92f3577b34da6a3ce929d0e0e4736

                    Select any span row to inspect its telemetry record.

                    0 ms143 ms286 ms

                    Selected span

                    store event

                    Duration
                    184 ms
                    Status
                    Unset
                    Source
                    Manual

                    Attributes

                    Inspect conceptual span record

                    This keeps the important structure visible. Literal OTLP/JSON adds typed values and a more verbose envelope, and a real export may contain several spans.

                    This child span explains most of the end-to-end latency. The trace narrows the investigation; it does not prove the underlying cause.

                    18

                    Friction

                    Workflow loop
                    Ready

                    Workflow loop lab

                    Trace a human-agent change loop

                    Choose the workflow shape Friction appears in feedback, review packages, and correction loops.

                    Workflow shape

                    The human reads, edits, tests, and prepares the review package.

                    Loop map

                    Feedback evidence

                    Score what the workflow can prove before a human reviewer reads the diff.

                    Loop pressure

                    Likely correction loops
                    0
                    Human review load
                    0 min
                    Automation leverage
                    -

                    Strong feedback turns review comments into faster local signals.

                      Review package

                      Review package

                      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.

                      Sign in to save

                      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.

                      Practice in the chapter →

                      19

                      Friction

                      Friction audit
                      Ready

                      Friction audit lab

                      Find the slow part of a small change

                      Score the change path Friction compounds when setup, tests, review, and context fail.

                      Change request

                      A new event type needs one required field in the UI, API, storage, and summary view.

                      Likely touch points

                        In this mode, you do the search, edit, test, and review work manually.

                        Estimate basis

                        The agent multipliers are bounded by published developer productivity studies: a constrained Copilot task was 55.8% faster, while a 2025 open-source field experiment found experienced developers 19% slower with AI tools on mature projects.

                        • Peng et al. 2023
                        • Becker et al. 2025
                        • Zhang et al. 2023

                        What slows this down?

                        Change process

                        Audit result

                        Estimated change cost
                        0 min
                        Likely rework loops
                        0
                        Agent rework risk
                        -
                        Largest source
                        -

                        Choose one feedback loop

                        Everyone starts from the same runnable project and known data.

                        Impact

                        Before
                        0 min
                        After
                        0 min
                        Time saved
                        0 min

                        Pick a feedback loop to see what repeated work it removes.

                        Friction audit artifact

                        Friction audit artifact

                        20

                        Reality

                        Changed assumptions map
                        Ready

                        Incident response challenge

                        Keep the event pipeline useful

                        Round 1 of 3 · Find the boundary The conference doors just opened. Commit to evidence before changing the system.
                        Model boundary This deterministic scenario teaches pressure, feedback, and trade-offs. Its values are not measured capacity for a real deployment.
                        1. 01
                          DetectFind the first limit
                        2. 02
                          ContainBreak the retry loop
                        3. 03
                          RecoverProtect shared capacity
                        4. 04
                          DebriefDefend the trade-off
                        Live system

                        Conference check-in

                        09:02
                        Mission

                        Preserve trustworthy event recording and a useful dashboard while demand, retries, and one large import test different boundaries.

                        01
                        IngressEvent API
                        Accepting
                        02
                        CommitEvent store
                        Pool waiting
                        03
                        DeriveProcessors
                        Keeping up
                        04
                        ReadDashboard
                        Current
                        Write p95 310 ms target ≤ 250 ms
                        Oldest event 28 s target ≤ 60 s
                        Duplicate effects 0 target ≤ 2
                        Modeled usefulness 100% target ≥ 75%
                        Explicit rejection 0% budget ≤ 20%
                        Change budget 6 spend deliberately

                        Shift log

                        Consequences persist into the next round
                        1. 08:55

                          Baseline stable at 75 events per second.

                        2. 09:02

                          Arrival demand crosses the current capacity envelope.

                        Round 01 · Detect

                        Writes slow while API CPU remains quiet

                        6 units

                        Which signal identifies the first binding limit, and what is the smallest defensible response?

                        What everyone can see
                          Investigate one signal
                          Probe not selected

                          Choose one signal to reveal its reading before you act.

                          Commit one response

                          The response and its displaced complexity will carry into the next round.

                          Incident debrief

                          Pressure map ready

                          —

                          Observed pressure map

                          Defend the operating decision

                          1. Which signal revealed the first binding limit?
                          2. Where did each response move complexity or user-visible cost?
                          3. Which result is modeled, and what would still need measurement?
                          Incident pressure brief

                          Copyable project evidence

                          Pause & think

                          Count the effects of a retry

                          An event request commits once, but its response is lost. The client retries on another instance. There is no deduplication, and that retry also commits once. Count the stored effects, then select the mechanism that prevents this duplicate effect when the same operation is retried.

                          Automatically checked practice. Saved answers are private to your account.

                          Sign in to save

                          Checking saved answers…

                          Your answers to earlier versions
                          Show worked answer

                          There are two stored effects. Reusing a stable operation key works when authoritative storage atomically records the mutation and reusable result under that key. A per-instance cache cannot coordinate retries routed elsewhere.

                          Practice in the chapter →

                          21

                          Appendix D: Agent-system security

                          Fleet trace debugger
                          Ready

                          Compare forensic lab

                          Reconcile what the fleet actually used

                          0 of 5 ledger rows assigned Intent, mediation, and physical use are separate evidence streams.
                          01

                          Inspect the fixed packet

                          Compare orchestration intent with gateway decisions before touching the physical ledger.

                          Packet FLT-17A Gateway export complete
                          R41
                          Patch event filter tr-41 · outcome accepted
                          Accepted
                          R42
                          Publish audit notice tr-42 · outcome cancelled
                          Cancelled
                          ORCH
                          Orchestration log
                          Run intent and outcomes
                          Time Run Event Evidence
                          GATE
                          Gateway log
                          Selected route and policy result · complete export
                          Request Run / trace Selected resource Policy
                          02

                          Attribute every physical row

                          Map each provider or resource record to R41, R42, or unmatched. Do not infer a run where the linking evidence is absent.

                          0 / 5 mapped
                          PHY
                          Provider and resource ledger Authoritative provider spend and tool-effect records
                          Row Time Physical operation Linking evidence Result Cost Map to Reconciliation

                          Assign every row before reconciling the packet.

                          03

                          Reconciled control record

                          Each physical row is counted once, including failed, cancelled, and unmatched work.

                          5 / 5 accounted
                          Physical rows
                          5
                          Accepted runs
                          1
                          Fixed-cohort cost
                          0.00 EUR
                          Cost / accepted run
                          0.00 EUR
                          Run and route rollup
                          Attribution Outcome Rows Selected route / policy Cost
                          Consequential findings
                            Export the reconciliation record

                            The record preserves mappings, route and policy provenance, all costs in the packet, and the denominator used for the result.

                            22

                            Agent fleets

                            Agent fleet delegation
                            Ready

                            Compare delegation lab

                            Plan a small agent fleet

                            Choose a task You remain responsible for integration and review.

                            Scenario

                            Fleet roles

                            Model assignment

                            Match model strength to role difficulty. Direct cost is only one part of the decision; review and rework can dominate the workflow.

                            Recommended workflow

                              Coordination
                              0
                              Integration risk
                              Low
                              Best pattern
                              Single agent
                              Model cost
                              0.00 EUR
                              Model latency
                              0 min
                              Review time
                              0 min
                              Rework risk
                              Low

                              Choose roles and models to compare direct model cost with review burden.

                              Run packet

                              Copyable prompt packet

                              23

                              Appendix E: Scalability models

                              Reliability chain lab
                              Ready

                              Lusser’s Law · Rworkflow = ∏ri

                              Track the error that survives every safeguard

                              60.6% completes correctly

                              01 / Calibrate one critical step

                              Idealized boundary: identical independent steps, every step required, and the first terminal outcome decides the run.

                              One step · prediction or recovered error r = .950 + (.050 × .900 × 1.000) = 99.500%
                              Series chain · every critical step succeeds R(100) = .99500^100 = 60.6%
                              Correct completion across the chain 60.6%
                              0 stepsCritical chain →200 steps
                              Where runs end Correctness and safety are separate
                              Step gate
                              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.

                              24

                              Agent fleets

                              Sequential work bound
                              Ready

                              Amdahl’s Law · S(N) = 1 / ((1 − p) + p/N)

                              Find the work that more agents cannot remove

                              2.50× ideal speedup

                              01 / Describe the workflow

                              The ideal bound excludes coordination, conflicts, retries, and review queues.

                              One agent100%
                              4 agents
                              40%
                              SequentialParallel share after division
                              Ideal speedup
                              2.50×
                              Relative time
                              40.0%
                              Efficiency
                              62.5%
                              Infinite-agent ceiling
                              5.00×

                              Four agents divide the parallel work, but the sequential 20% remains.

                              Pause & think

                              Calculate the parallel speedup

                              Assume 80% of a fixed task can run in parallel, 20% is sequential, and coordination has no cost. Use S(N) = 1 / (0.2 + 0.8 / N). Calculate the speedup with four workers and the limit as the worker count grows without bound.

                              Automatically checked practice. Saved answers are private to your account.

                              Sign in to save

                              Checking saved answers…

                              Your answers to earlier versions
                              Show worked answer

                              Four workers give 1 / 0.4 = 2.5 times the original speed. Even infinitely many workers leave the sequential 20%, so the limit is 1 / 0.2 = 5. Coordination costs would reduce these ideal results.

                              Practice in the chapter →

                              25

                              Scaling

                              Scaling pressure planner
                              Ready

                              Compare scaling lab

                              Choose scaling moves for one pressure

                              Describe the pressure A scaling choice is only defensible when the pressure, cost, and signal are explicit.

                              Event tracker pressure

                              Pressure levels

                              Candidate moves

                              Selection rule

                              Choose the smallest set that addresses the named pressure. Every extra move must pay for itself with a benefit, signal, and failure story.

                                Resulting design

                                  Write relief
                                  0/10
                                  Read relief
                                  0/10
                                  Freshness risk
                                  Low
                                  Operational complexity
                                  Low
                                  Resource cost
                                  Low
                                  Waterbed lens
                                  Trace displaced complexity
                                  Choose a scaling move

                                  Select techniques to see the trade-off.

                                  Trade-off table

                                  Copyable scaling artifact

                                  26

                                  Scaling

                                  Saturation boundary lab
                                  Ready

                                  Capacity envelope

                                  Find the first binding limit

                                  Inspecting pipeline Compare effective demand with every stage.

                                  Disturbance

                                  Declared stage capacity

                                  Effective demand 147 ev/s offered load + retries
                                  Boundary —
                                  Headroom —
                                  Hidden backlog —
                                  Rejected explicitly —

                                  Adjust demand or capacity to expose a boundary.

                                  First useful signal
                                  —
                                  Prepared recovery
                                  —
                                  Next closest boundary
                                  —
                                  Boundary report

                                  Copyable saturation analysis

                                  This is a teaching model, not a capacity benchmark. It compares one effective demand rate with declared stage limits so the movement of a bottleneck is visible.

                                  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.

                                  Sign in to save

                                  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.

                                  Practice in the chapter →

                                  27

                                  Appendix E: Scalability models

                                  Contention curve lab
                                  Ready

                                  Universal Scalability Law · C(N)

                                  See when adding concurrency starts taking capacity away

                                  Capacity is still rising

                                  01 / Shape the scaling cost

                                  1 workerConcurrency →32 workers
                                  Selected capacity
                                  5.57×
                                  Peak at
                                  22
                                  Peak capacity
                                  7.33×
                                  Next worker
                                  helps

                                  At eight workers, added concurrency still increases modeled capacity.

                                  28

                                  Scaling

                                  Orchestration control loop
                                  Ready

                                  Browser cluster lab · Webernetes

                                  Watch the control loop close

                                  Starting simulated cluster… Controllers are assembling a three-node teaching environment.
                                  Simulation boundary This runs Kubernetes-compatible control logic in your browser. It does not run Docker images or measure production capacity.
                                  Desired 3
                                  Running 0
                                  Release v1
                                  Served 0
                                  NodePort service · :31000 event-api
                                  round robin
                                  01node-1
                                    02node-2
                                      03node-3
                                        Controller feed Newest event first
                                        Reconciling
                                          Debrief the mechanism and its limits

                                          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.
                                          29

                                          Appendix F: Durable workflows

                                          Durable effect retry lab
                                          Ready

                                          Scaling failure lab

                                          Crash between effect and checkpoint

                                          Predict the recovery outcome One command can produce more than one physical attempt.
                                          01

                                          Set the retry contract

                                          Choose the facts that survive the worker.

                                          After recovery, how many webhook effects exist?
                                          02

                                          Follow the failure window

                                          The fault sits outside the durable history boundary.

                                          1. 01
                                            Schedule History records attempt 1
                                          2. 02
                                            Send Worker calls the receiver
                                          3. 03
                                            Apply Receiver commits the effect
                                          4. !
                                            Crash seam Completion never reaches history
                                          5. 04
                                            Recover Replay sees incomplete work
                                          Failure injector armed

                                          The first worker will stop after the receiver replies and before ActivityCompleted is stored.

                                          Logical commands
                                          0
                                          Activity attempts
                                          0
                                          Outbound calls
                                          0
                                          Webhook effects
                                          0
                                          Durable completions
                                          0
                                          A

                                          Authoritative application state

                                          The domain fact and requested delivery.

                                          Event
                                          E42 · stored
                                          Command
                                          deliver:E42:subscriber-7
                                          Delivery state
                                          Ready
                                          Last durable fact
                                          None
                                          H

                                          Workflow history

                                          Only durable orchestration facts appear here.

                                          Seq History event Replay knows
                                          Run the first attempt to create history.
                                          R

                                          Webhook receiver ledger

                                          Attempts and externally visible effects.

                                          Try Idempotency key Receiver reply Effect
                                          No webhook attempts yet.
                                          ?
                                          Awaiting experiment

                                          Make a prediction, then stop the worker inside the failure window.

                                          Export the evidence record

                                          Failure-window record

                                          Preserve the configuration and all four counts instead of reporting only the final workflow status.

                                          30

                                          Scaling

                                          CAP partition lab
                                          Ready

                                          Distributed data fault table

                                          Decide what happens across a partition

                                          All regions can communicate Cut the network before testing the write policy.

                                          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.

                                          HEL connected
                                          Helsinki
                                          Item state
                                          initial
                                          Visible event
                                          none
                                          Client reply
                                          waiting
                                          healthy network
                                          FRA connected
                                          Frankfurt
                                          Item state
                                          initial
                                          Visible event
                                          none
                                          Client reply
                                          waiting
                                          DUB connected
                                          Dublin
                                          Item state
                                          initial
                                          Visible event
                                          none
                                          Client reply
                                          replica
                                          LOG

                                          Request and repair log

                                          Responses are facts too; reconciliation cannot un-send one.

                                          1. 00

                                            Replicas agree that I42 is initial.

                                          Accepted writes
                                          0
                                          Rejected writes
                                          0
                                          Conflicts to repair
                                          0
                                          C Atomic consistency
                                          One current value
                                          A Availability
                                          No partition yet
                                          P Partition condition
                                          Network connected
                                          ↔
                                          Architectural reading

                                          CAP has not constrained the request path yet

                                          With communication intact, the replicas can coordinate before they answer.

                                          The model holds workload, topology, and failure constant so the policy is visible. Real systems define quorums, timeouts, leases, conflict resolution, and consistency guarantees more precisely.

                                          31

                                          Scaling

                                          Latency budget map
                                          Ready

                                          Latency budget lab

                                          Count distance and database waits

                                          Build the request path The numbers are approximate, but the accumulation pattern is real.

                                          Request topology

                                          Edge read replica

                                          Reads stay close to the application, but writes may still coordinate with a primary database.

                                          Physical floor

                                          User App DB
                                          User to app 500 km 5.0 ms RTT floor
                                          App to DB 1 km 0.0 ms RTT floor

                                          Map derived from BlankMap-World.svg by Canuckguy and contributors, public domain, via Wikimedia Commons.

                                          In fiber, light travels at roughly 200,000 km/s. That is about 200 km per millisecond one way, before routing, queues, TLS, server work, or database execution.

                                          User RTT floor
                                          0 ms
                                          App-DB RTT floor
                                          0 ms

                                          Database access pattern

                                          Typical production instance

                                          Ordinary compute and database performance: hardware matters, but round trips can still dominate.

                                          Compare access shapes

                                          Sequential DB wait
                                          0 ms
                                          If batched into 2 trips
                                          0 ms
                                          Round-trip penalty
                                          0 ms
                                          Network per DB trip
                                          0 ms
                                          Server execution
                                          0 ms

                                          Edge read replica

                                          Reads stay close to the application, but writes may still coordinate with a primary database.

                                          Edge placement helps read-heavy paths most. It does not remove consistency, replication, or write-routing trade-offs.

                                          Latency budget

                                            Totals

                                            Estimated response
                                            0 ms
                                            Physical network floor
                                            0 ms
                                            Avoidable DB wait
                                            0 ms
                                            100-request page cost
                                            0 s

                                            Interpretation

                                            Adjust distance and database access to see what dominates.

                                            32

                                            Recap

                                            Final reflection package
                                            Ready

                                            Final reflection package

                                            Build a reflection from course artifacts

                                            Pick project evidence A strong reflection names the artifact, the claim it supports, and the limitation it does not prove.

                                            Artifacts in your folder

                                            What to add before writing

                                              Draft package

                                              More practice

                                              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.

                                              Sign in to save

                                              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.

                                              Practice in the chapter →

                                              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.

                                              Sign in to save

                                              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.

                                              Practice in the chapter →

                                              Elements of Scalable Web Development by Juho Vepsäläinen.