Introduction evidence decisions
Every project was considered separately. Extra material is included only where it explains the application, failure, interface or a decision-driving constraint. These are editorial decisions, not automated checks or claims of production observation.
| Project | Intro material and reason |
|---|---|
| Build a private bookmark API with ownership and version checks | Sizing: 10,000 users with 20 bookmarks each means 200,000 records |
| Build short links with unique aliases and safe redirects | Sizing: 30 million creations/day is roughly 300 requests/s (RPS) using 100,000 seconds/day, or 347 RPS using the exact day length |
| Enforce API quotas across concurrent gateways | Proposed response shows what rejection means to a real caller. |
| Build checkout that recovers from uncertain payments | Animated failure order and proposed status response make a lost reply distinct from a failed charge. |
| Record permission changes with durable audit evidence | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Enforce tenant access in APIs, caches and exports | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build restartable CSV export jobs | Ownership-takeover animation explains why late completion must be rejected. |
| Schedule reports without duplicate logical runs | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Erase account data across stores and in-flight work | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Migrate tenant data with a resumable backfill | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Design and rehearse regional write failover | Sizing: At 3,000 writes/s, a replica that is 20 seconds behind may be missing roughly 60,000 recent writes |
| Reserve rooms and handle recurring local times | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Reserve concert seats with expiring holds | Sizing: The sale receives 60,000 purchase attempts/s for 20 seconds: 1.2 million attempts for 30,000 seats |
| Assign drivers safely with expiring offers | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build chat with durable messages and reconnect recovery | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build a versioned shared document editor | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Deliver notifications with preferences and priority | Sizing: One million campaign recipients in ten minutes means about 1,667 submissions/s before retries |
| Deliver signed webhooks with retries and replay | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build restaurant discovery and authoritative checkout | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build a following feed with current access checks | Sizing: At 120,000 feed requests/s with 30 items per page, the service may need to consider 3.6 million candidate items/s |
| Collect news feeds with freshness and deduplication | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Process uploads and publish complete video renditions | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build resumable uploads and authorized video playback | Sizing: Five million uploads/day averages about 58 uploads/s |
| Run programming submissions inside isolated workers | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build versioned API routing and admission policies | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Ingest events with durable acceptance and replay | Sizing: A burst of 100,000 events/s at 1 KiB each carries about 97.7 MiB/s of raw input |
| Aggregate click events with late arrivals and reconciliation | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Compute trending topics from duplicate and late events | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Protect a database with versioned cache fills | Real code excerpt explains stale fills and explicitly names the missing distributed atomicity. Sizing: The assumed two million reads/s cannot all fall through to a database budgeted for 10,000 reads/s |
| Implement replicated writes and fenced leadership | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Search documents without leaking revoked content | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build typeahead with stale-response protection | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Synchronize files with resumable uploads and conflicts | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build a durable crawler with per-host limits | Sizing: One billion waiting URL entries at 200 bytes each is about 200 GB before indexes and history |
| Release invoice changes with stable cohorts and rollback | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Find database-pool waiting in slow API requests | Actual local diagnostic output and phase animation show why query duration alone misses the incident. |
| Ingest and query metrics with bounded cardinality | Illustrative telemetry input reveals why unique labels increase cardinality. Sizing: 300,000 hosts reporting every ten seconds produce 30,000 host reports/s |
| Reject excess API work before queues grow without bound | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build a document assistant with current permissions | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Draft support replies without granting tool authority | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Serve recommendations with safe fallback ranking | Sizing: The 250 ms response target has to include the whole user-visible operation |
| Trace requests through a bookmark API | Actual save request/response plus animated current local flow. No traffic calculation is needed to understand overlapping requests. |
| Enforce a single deadline across API dependencies | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build an SSRF-resistant link preview fetcher | Actual policy-model output explains the private/mixed-address cases without presenting a complete secure HTTP client. |
| Evolve tag responses without breaking old clients | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Move title lookup into restartable background jobs | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build duplicate-safe form submission and CSV export | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Store receipts with reviewable extraction and corrections | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build a shared reading-list UI with private reading state | Actual supplied conflict response anchors the UI behavior in a concrete interface. |
| Prevent overlapping shifts and enforce manager access | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Measure whether existing checks detect real defects | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Protect API response types, units and compatibility | Small API-spec excerpt exposes the precise type and unit issue. |
| Reproduce and remove order-dependent failures | Illustrative failure transcript makes the hidden input visible. |
| Measure API capacity with controlled arrival rates | Sizing: 120 arrivals/s minus 100 completions/s adds roughly 20 waiting requests each second when nothing is rejected |
| Design and run a synthetic reading-list journey | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Deploy from main and roll back compatible artifacts | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Diagnose a reading-list incident from existing telemetry | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Define and calculate a user-facing save SLO | Sizing: For one million eligible requests and a 99.9% success objective, the allowed failed-request count is 1,000 |
| Implement burn-rate alert and incident state rules | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Bound retries across browser, API and SDK layers | Actual local output connects retry multiplication and remaining time to the user operation. |
| Prioritize API work within a fixed capacity budget | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Recover a service trapped in expired work and retries | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Keep bookmark saves usable when title lookup fails | Actual supplied function makes optional enrichment and controlled dependency behavior visible. |
| Rehearse detection, rollback and service recovery | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build ingestion with bounded backlog and explicit rejection | Sizing: During the ten-second burst, producers offer 1,000 events while workers finish at most 200 |
| Build evidence-backed answers with permission rechecks | Proposed supported/abstaining response pair shows what the user receives. |
| Require exact human approval before agent actions | Illustrative action record gives exact meaning to parameter-bound approval. |
| Route extracted invoices through validation and review | Illustrative inconsistent invoice makes content errors different from transport failure. |
| Track AI evaluation evidence and serving versions | Small evaluation slice table shows why an average cannot decide permission safety. |
| Decide whether an AI feature improves a reading list | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Migrate tags across data, clients and workers | Before/after API data shapes make compatibility work concrete. |
| Build a service template with overridable defaults | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Write a data-platform policy from concrete decisions | Prose only: the concrete workflow or decision in the opening is sufficient. No scale, code or animation is needed. |
| Compare a small export script with a custom platform | Prose only: the concrete workflow or decision in the opening is sufficient. No scale, code or animation is needed. |
| Stage 1: Build the shared reading-list application | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Stage 2: Deploy, back up and recover the reading list | Explicit incident timeline explains recovery-point evidence without inflated traffic. |
| Stage 3: Add durable jobs and bounded caching | Sizing: 200 readers making one request/s offer 200 reads/s to a database budgeted for 100 |
| Stage 4: Add optional AI tag suggestions | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Stage 5: Migrate the reading list to stable tag IDs | Illustrative stale-backfill timeline anchors version and deletion handling. |
| Record and revisit uncertain engineering decisions | Prose only: the concrete workflow or decision in the opening is sufficient. No scale, code or animation is needed. |
| Specify tag behavior for independent implementers | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Evaluate generated rate-limiter code with a simple reference | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build reusable AI instructions and evaluate transfer | Prose only: the concrete workflow or decision in the opening is sufficient. No scale, code or animation is needed. |
| Collect evidence about changed behavior and affected callers | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Rewrite private commit history to explain a change | Prose only: the concrete workflow or decision in the opening is sufficient. No scale, code or animation is needed. |
| Split a tagging feature into runnable changes | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Check the combined behavior of independently valid changes | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Automate deterministic review rules and retain human judgment | Prose only: the concrete workflow or decision in the opening is sufficient. No scale, code or animation is needed. |
| Demonstrate CI enforcement in a disposable repository | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |
| Build a link monitor with durable history and change alerts | The user story and action/result walkthrough explain the key behavior. Keep the detailed workload and implementation evidence later in the page. |