Production architecture and inference serving

Test service capacity under bursts, not just average demand.

Visual lessons: 1 · 1:41 total Read estimate: 5 min Practice estimate: 12 hr Updated: 2026-10-03
In this lesson · P4 of 12All lessons in this track →

Progress for this track is saved in this browser only. No completion badge is issued. View your learning.

Start with the idea

Test service capacity under bursts, not just average demand.

A system can handle typical traffic and fail when requests arrive together. Check service rate, waiting and fallback behavior. Measure the test setup’s own limits too.

p95 latency: The time at or below which 95 percent of the measured requests completed.

See the example and check your understanding

A made-up teaching example

Two simulated designs have different service rates and queue limits. One meets a median target but fails the p95 target during bursts. The decision records the alternative and an offline fallback.

Ask yourself

Does a queue limit alone prove the p95 target?

Show the explanation

No. Measure the workload. Check units and whether the load generator itself limited the test.

Start with these checks

  • Test bursts and normal load.
  • Check units in capacity estimates.
  • Record fallback and test limitations.

Use the different practice case below and check every requirement in its full instructions.

Go to the practice task ↓

The video explains the main idea. Use the sources, instructions and checks below to complete the practice.

Visual lesson1:41

Captions appear here during playback.

Production architecture and inference serving

Test service capacity under bursts, not just average demand.

Download transcriptOpen video file

Source-based teaching example · Fictional data · Reviewed 2026-10-03. Microsoft Mark · locally synthesized. On a small screen, use fullscreen for diagram details or read the transcript.

Read the descriptive transcript

0:00 · What you will learn

Test service capacity under bursts, not just average demand.

What appears on screen

Test service capacity under bursts, not just average demand.

0:07 · The idea

A system can handle typical traffic and fail when requests arrive together. Check service rate, waiting and fallback behavior. Measure the test setup’s own limits too.

What appears on screen

A system can handle typical traffic and fail when requests arrive together. Check service rate, waiting and fallback behavior. Measure the test setup’s own limits too.

0:21 · One useful term

p95 latency. The time at or below which 95 percent of the measured requests completed.

What appears on screen

The time at or below which 95 percent of the measured requests completed.

0:30 · A worked example

Two simulated designs have different service rates and queue limits. One meets a median target but fails the p95 target during bursts. The decision records the alternative and an offline fallback.

What appears on screen

Two simulated designs have different service rates and queue limits. One meets a median target but fails the p95 target during bursts. The decision records the alternative and an offline fallback.

0:47 · Your turn to think

Does a queue limit alone prove the p95 target? Pause and decide before continuing.

What appears on screen

Does a queue limit alone prove the p95 target? Pause the video if you need more time.

1:04 · Why this answer works

No. Measure the workload. Check units and whether the load generator itself limited the test.

What appears on screen

No. Measure the workload. Check units and whether the load generator itself limited the test.

1:13 · Check 1

Test bursts and normal load.

What appears on screen

Test bursts and normal load.

1:18 · Check 2

Check units in capacity estimates.

What appears on screen

Check units in capacity estimates.

1:23 · Check 3

Record fallback and test limitations.

What appears on screen

Record fallback and test limitations.

1:29 · Now try a different case

Open the lesson and try its different practice case. Use every check in the full task. Watching alone does not mark the lesson complete.

What appears on screen

Open the lesson Try the new case Check and revise The full task and its requirements are in the linked lesson.

Watching explains the example. Complete the lesson practice to check what you can do. Explore all visual lessons →

What you will be able to do

  1. Translate workload and SLOs into capacity.
  2. Compare managed, hosted, and on-premises options.
  3. Design queuing, backpressure, caching, and degradation.

Prerequisites: Builder-level interface validation, Python, testing, metadata logging and state-transition tracing. Hardware benchmarks and model accounts are not required.

This curriculum runs self-study on VetsLearn. Where the text calls for an instructor, peer or formal review, use the stated acceptance criteria for self-review. Reflection questions support reflection; they do not replace independent assessment. A peer review is optional unless your actual organization requires it.

Part 1 Technical instruction

Architecture begins with workload: arrival rate, concurrency, token distribution, latency objective, availability, data boundary, and failure consequence. Average latency is not capacity evidence; use percentiles and burst behavior. Queues absorb short bursts but create wait time and can amplify overload. Backpressure rejects or sheds work before collapse. Caches need identity, authorization, version, and freshness keys. Graceful degradation might shorten context, use a validated smaller model, return retrieval-only results, or abstain. Every option needs an exit and rollback strategy.

Mechanism and implementation

Capacity depends on arrival rate, service time, burstiness and variance. Little’s law relates average in-system work, arrival rate and residence time under stable conditions; it is not a tail guarantee. Bound queues and admission before overload. Local deployments can be production systems with proper operational ownership.

Constructed offline example

Save as topic_example.py and run python topic_example.py with an installed Python 3.11+ interpreter. This standard-library construction uses synthetic values; its checks are not provider measurements.

arrival, mean_seconds = 2, 3
assert arrival * mean_seconds == 6
capacity = 4
admitted = []
for request_id in range(7):
    if len(admitted) < capacity:
        admitted.append(request_id)
assert len(admitted) == 4
print("admitted", len(admitted), "deferred", 7 - len(admitted))

Engineering decisions

  • Define SLO and saturation signals.
  • Select deployment boundary from authorization evidence.
  • Choose degradation that preserves safety and user expectations.

Worked example

Two simulated architectures have different service rates and queue limits. The capacity model shows one meets median latency but fails p95 during bursts. The ADR selects the second and documents an offline fallback.

Diagnose the failure

Units must cancel correctly. A queue cap alone cannot prove p95 latency. Measure load-generator limits before attributing failures to serving.

Part 2 Guided practice

Calculate average in-system work and contrast it with queue capacity. Add defer/reject statuses and a retry deadline. Independently compare approved local and hosted routes for the same workload.

Answer criteria and feedback: Units must cancel correctly. A queue cap alone cannot prove p95 latency. Measure load-generator limits before attributing failures to serving.

Continue with the downloadable pack below. If the pack or interpreter is unavailable, trace this self-contained example by hand in an input/expected-status/controlling-rule table and label execution unverified. Do not invent passing output. No account, credential, paid call, purchase or actual deployment is required.

Part 3 Remediation

Check units: requests/second, seconds/request, tokens/request, and concurrency. Reproduce one estimate manually before trusting the simulator. After repair, reassess with the alternate scenario in scenario_alt.json. A critical authorization, data-handling, evidence-integrity, or prohibited-action failure cannot be averaged into successful practice; it requires targeted remediation.

Part 4 Sources and currency

Use the workflow decision reference for model/deployment/harness distinctions and controlled comparisons. Source currency must be checked before each cohort. Provider/product behavior is illustrative where mocked; resolve current interfaces only from official documentation in an authorized environment.

Lesson status:PRACTICE REVIEW REQUIRED

Review your practice