Every weekday morning, in every timezone, a wall of humans opens their laptops within the same fifteen minutes and expects their video call to connect instantly. This chapter unpacks why that shared cultural habit turned into one of the most distinctive load patterns in modern infrastructure.

Every weekday morning, something remarkable and mildly terrifying happens inside the data centers of every major video conferencing company. Somewhere between 8:55 AM and 9:05 AM local time, in every populated timezone on Earth, a wave of humans opens their laptops, clicks “Start Meeting” or “Join,” and expects the call to connect in under two seconds. This isn’t a gradual ramp — it’s closer to a cliff. Traffic that was idling at 5% of peak capacity at 8:50 AM can be at 400% of average load by 9:02 AM, then fall back down by 9:15 AM once everyone has settled into their stand-ups.

This pattern is sometimes called the “9 AM problem” or, more formally, a synchronized demand spike — a burst of correlated, near-simultaneous requests triggered by human behavior rather than by any single external event like a news headline or a product launch. It’s a cousin of the classic thundering herd problem, but with a twist: the herd isn’t reacting to a system event (like a cache expiring), it’s reacting to a wall clock and a shared cultural convention — the standard workday start time.

Video conferencing platforms are especially vulnerable to this because a “meeting create” request isn’t just a database write. It’s the trigger for a cascade: allocating a unique meeting room, provisioning media relay capacity, warming up signaling servers, generating cryptographic keys for end-to-end encryption, registering the meeting with calendar integrations, and preparing to accept dozens or hundreds of concurrent audio/video streams the moment participants join. A single click by a user can fan out into ten or more downstream service calls.

Historically, this kind of load pattern existed long before video conferencing — ticket-sales flash sales, tax-filing-deadline traffic, and New Year’s Eve SMS spikes all share the same DNA. But video conferencing adds a unique constraint: the tolerance for failure is nearly zero and highly visible. If a flash sale website is slow, users see a spinner. If a video call fails to start, a person is late to a meeting in front of their boss, and the incident becomes a trending topic within minutes. This visibility is why companies like Zoom, in early 2020, had to re-architect significant parts of their meeting-creation pipeline within weeks as the world shifted overnight from optional video calls to mandatory daily infrastructure.

Before designing anything, we need to precisely define what we are protecting against. There are actually three distinct but related surges happening around the same time window, and conflating them is a common mistake in system design interviews.

2.1 The Three Surge Types

This document focuses primarily on the meeting creation surge as scoped in the problem statement, but because these three surges overlap in the same 10-minute window in practice, any production-grade design must account for all three, and we will touch on join and auth surges where they materially affect the creation path.

2.2 Why “Just Add More Servers” Doesn’t Work

A naive answer is “auto-scale the servers.” This fails for several reasons that are worth stating explicitly because they are exactly what a senior interviewer is listening for:

• Scale-up lag: Cloud auto-scaling (adding new VM/container instances) typically takes 60–300 seconds to provision, boot, and pass health checks. A surge that goes from baseline to peak in under 90 seconds will already have caused failures before new capacity is ready.
• Database is the real bottleneck: Stateless API servers scale horizontally easily; the relational database backing meeting metadata does not scale writes horizontally without significant re-architecture (sharding, partitioning).
• Downstream fan-out amplifies load: If each meeting-create call triggers 5–8 downstream calls (room allocation, media server reservation, calendar sync, notification dispatch, analytics event, billing/quota check), a surge of 1 million requests becomes 5–8 million downstream operations.
• Cost: Provisioning enough steady-state capacity to handle peak-of-peak load 24/7 (when the surge lasts roughly 15–20 minutes per timezone) is economically wasteful — this is the classic capacity vs. cost trade-off central to this entire design.

2.3 Design Goals

The design centers on a principle we’ll revisit throughout this document: decouple the fast path from the slow path. The fast path is the minimum set of operations required to hand the user a working meeting ID and join URL. The slow path is everything else — calendar invites, analytics, transcription pre-warming, compliance logging — which can happen asynchronously within a few seconds without the user noticing.

3.1 Component Breakdown

Zooming in on how a single meeting-create request actually flows through the fast path — and how the system decides whether to let the request in at all.

4.1 The Admission Control Layer

The single most important architectural decision for surviving a surge is admission control — deciding, in microseconds, whether to accept a request at all, before it consumes any expensive downstream resource. This is implemented as a layered set of checks:

1. Global circuit breaker check: Is the overall system in a degraded state? If so, reject with a fast, honest 503 and a “retry-after” hint rather than let the request queue behind an already-failing dependency.
2. Per-user/per-org token bucket: Prevents any single tenant from consuming disproportionate capacity during the surge (a large enterprise with 50,000 employees starting their day shouldn’t starve smaller customers).
3. Adaptive global rate limit: A dynamically adjusted ceiling on total meeting-creation throughput, informed by real-time capacity signals from the media scheduler and database shard health.

4.2 Idempotent, Minimal Fast-Path Writes

The fast path performs the absolute minimum work needed to hand back a valid meeting ID and join token:

• Generate a unique meeting ID using a distributed ID generator (no round trip to a central sequence).
• Write a minimal record (meeting ID, owner ID, org ID, creation timestamp, status = “pending”) to the appropriate shard — a single indexed insert.
• Reserve a soft capacity slot with the room allocation service — not a hard media server binding, just a promise that capacity exists in the target region.
• Publish a “meeting created” event to Kafka for all downstream, non-blocking work.
• Return the meeting ID and join URL to the client.

Everything else — populating recurrence rules, syncing to external calendars, sending invite emails, pre-warming transcription models, writing audit logs — happens asynchronously from the Kafka event, consumed by independently scalable worker pools that can lag behind during a surge without the user ever noticing, as long as they catch up within a few seconds.

4.3 Idempotency Keys

Mobile networks and flaky Wi-Fi mean clients will retry requests. Every meeting-create call carries a client-generated idempotency key. The Meeting Creation Service checks a short-TTL cache (Redis) for this key before doing any work; if seen before, it returns the previously generated meeting ID rather than creating a duplicate. This is critical during a surge, when client-side timeouts and retries spike in tandem with server load, creating a feedback loop that can double or triple effective load if not handled.

Trace a single meeting-create call end-to-end, then watch the meeting record move through its lifecycle from pending to archived.

5.1 Lifecycle Stages

1. Pending: Meeting record created, capacity reserved, no participants yet.
2. Active: First participant joins; media server binding finalized; SFU resources allocated.
3. In-progress: Ongoing call; signaling and media flowing.
4. Ended: Last participant leaves; resources released back to the pool; async workers finalize recordings and analytics.
5. Archived: After a retention window, moved to cold storage tiers.

Notice that the expensive media server binding happens at the Active stage, not at creation. This lazy binding is what allows the system to accept millions of “pending” meetings during a surge without needing millions of dedicated media server slots simultaneously — many scheduled or created meetings never actually start immediately, and even those that do join in a staggered fashion over the following seconds to minutes.

5.2 Handling the “Double Surge” from Recurring Meetings

A large fraction of the traffic in the 9 AM window isn’t new meeting creation at all — it’s the daily instantiation of recurring meetings (standups, syncs) that were scheduled weeks earlier. These recurring meeting instances still need an “occurrence record” created for that specific day, which means the system experiences two overlapping surges: brand-new ad-hoc meetings created by users clicking “New Meeting,” and a wave of recurring-meeting occurrence materialization jobs triggered by the calendar system itself, often just before the scheduled start time.

The design handles this by pre-materializing recurring meeting occurrences well ahead of time — typically the night before, during low-traffic hours — rather than generating the day’s occurrence record at the moment of the surge. This converts what would otherwise be an enormous synchronous burst of “create meeting occurrence” writes into a background batch job that runs when the database has ample spare capacity. Only the lightweight “activate this pre-existing occurrence” operation happens during the actual surge window, which is a far cheaper read-modify-write than a full record creation.

5.3 State Machine for a Meeting Record

No design choice is free. This chapter names the trade-offs behind each pillar of the fast-path / slow-path architecture explicitly, so the design is defensible in a review.

The single biggest lever for handling this surge is exploiting the fact that it’s predictable. Reactive auto-scaling alone always loses; prediction plus reaction wins.

7.1 Predictive Pre-Scaling by Timezone

Because the surge is periodic and largely predictable — it happens roughly every 24 hours, staggered by timezone — the system doesn’t need to rely solely on reactive auto-scaling. A predictive scaling controller ingests historical load curves per region and pre-warms capacity 10–15 minutes ahead of each region’s local 9 AM, well before reactive metrics like CPU or request rate would trigger a scale-out event.

This hybrid model — predictive pre-scaling as the primary mechanism, with reactive auto-scaling as a safety net for deviations from the prediction — is the industry-standard pattern for handling any periodic, correlated load, whether it’s a video conferencing morning rush, a streaming service’s prime-time spike, or an e-commerce flash sale with a known start time.

7.2 Distributed ID Generation at Scale

A naive auto-incrementing primary key in a single database becomes a hard bottleneck the moment write throughput exceeds what a single leader node can serialize. The solution is a Snowflake-style distributed ID generator: each ID encodes a timestamp, a worker/shard identifier, and a local sequence number, allowing thousands of ID-generation nodes to mint unique, roughly time-ordered IDs with zero coordination between them.

7.3 Queue-Based Load Leveling

For work that doesn’t need to complete synchronously, the system uses queue-based load leveling: instead of processing every downstream task the instant a meeting is created, tasks are pushed to Kafka topics and consumed at a sustainable, independently-scaled rate. During the surge peak, the queue depth grows; workers drain it over the following seconds to minutes once the peak subsides. This converts a spike in arrival rate into a smoother processing rate, which is far cheaper to provision for.

7.4 Capacity Planning Numbers

7.5 Algorithmic Considerations: Rate Limiting Under Burst

Not all rate-limiting algorithms behave the same way under a sudden, correlated spike, which makes the choice of algorithm itself a meaningful design decision rather than an implementation detail:

In practice, the admission-control layer uses token bucket at the per-tenant level (to tolerate natural burstiness of real organizations) combined with leaky bucket-style smoothing at the boundary to the room allocation and media scheduling services, since those downstream systems have genuinely fixed physical capacity that cannot simply absorb a burst the way a stateless API server can.

7.6 Sizing the Warm Compute Pool

A useful back-of-envelope approach for sizing the pre-warmed compute pool ahead of a predicted surge: take the predicted peak requests-per-second for the region, divide by the sustainable throughput of a single fast-path service instance under realistic load-tested conditions (including safety margin for tail-latency degradation as instances approach saturation), and add a buffer — typically 20–30% — to absorb prediction error without falling back entirely on slower reactive scaling. This number is recalculated per region per day based on a rolling window of recent historical peaks, not fixed once and forgotten, since organic user growth steadily shifts the true peak upward over time.

A meeting-creation failure is highly visible — someone is late to a meeting in front of their boss. The reliability model has to assume dependencies will misbehave and still keep the fast path alive.

8.1 Multi-Region Active-Active

Because the surge itself is regionally distributed by definition (it follows timezones around the globe), the system is naturally suited to an active-active multi-region deployment. Each region independently serves its local surge; a region-level failure only affects users physically routed there, and GeoDNS can redirect traffic to the nearest healthy region during a regional outage — at the cost of increased latency for affected users until the primary region recovers.

8.2 Circuit Breakers and Bulkheads

Every downstream dependency of the Meeting Creation Service (room allocation, ID generator, database shard) is wrapped in a circuit breaker. If room allocation starts timing out under load, the circuit opens and the service falls back to a degraded mode: it still creates the meeting record and returns a join URL, but defers the room/capacity reservation to the join-time path instead of failing the entire request. This is a direct application of the bulkhead pattern — isolating failure domains so one struggling dependency cannot sink the entire fast path.

8.3 Graceful Degradation Ladder

This ladder ensures that the system degrades in a controlled, prioritized way rather than failing catastrophically all at once. Core meeting creation for paying enterprise customers is the last thing to be shed, not the first.

8.4 Disaster Recovery

• RPO (Recovery Point Objective): Sub-second for meeting metadata via synchronous replication within a region, cross-region async replication with a target RPO of under 5 seconds.
• RTO (Recovery Time Objective): Under 60 seconds for automated failover to a standby region via health-check-driven DNS failover.
• Backups: Point-in-time recovery snapshots for the sharded database, tested via regular restoration drills.

8.5 Testing Reliability: Surge-Specific Chaos Engineering

Standard chaos engineering practices (randomly killing instances, injecting network latency) validate general resilience but don’t specifically exercise the surge failure modes this design targets. A mature program adds surge-specific game days: replaying historical peak traffic shapes against a staging environment scaled to a fraction of production capacity (to intentionally induce the same relative overload), while independently injecting a downstream dependency failure (e.g., artificially slowing the room allocation service) during the simulated peak. The goal is to verify that the graceful degradation ladder actually engages in the correct order under realistic combined stress, not just under a single isolated fault — real incidents are far more often the product of two or three compounding issues than a single clean failure.

A surge window is exactly when the system has the least slack to spend on abuse mitigation — which is exactly when it needs it most. Security has to be fast, layered, and never a blocking dependency.

9.1 Abuse and Bot Protection During Surges

A legitimate surge and a coordinated abuse pattern (e.g., bot-driven meeting spam to exhaust free-tier resources, or a denial-of-service attempt disguised as organic traffic) can look superficially similar in raw request volume. The system must distinguish them:

• Behavioral fingerprinting: Legitimate surges show diverse, geographically-clustered-but-individually-distinct client patterns; abuse often shows anomalously uniform request timing or missing client telemetry.
• CAPTCHA/step-up challenges: Reserved for anomalous patterns only, never applied broadly during a legitimate surge, to avoid adding friction exactly when the system is already stressed.
• Per-account and per-IP quotas: Independent of the adaptive global rate limit, to cap the blast radius of any single compromised account or botnet source.

9.2 Meeting ID Unpredictability

Meeting IDs generated under load must remain cryptographically hard to guess, even though they’re being minted at extremely high throughput. The distributed ID generator’s output is combined with a separate random join-token component that is never derivable from the meeting ID alone, preventing enumeration attacks (“meeting scanning”) during high-volume creation windows.

9.3 Authentication Surge Handling

Because the auth surge overlaps with the meeting-creation surge, the token validation path (JWT signature verification, session lookup) must be extremely fast and horizontally scalable, typically via short-lived signed JWTs validated locally at the gateway without a database round trip, falling back to the session store only for revocation checks on a sampled or cached basis.

9.4 Encryption Key Provisioning

For end-to-end encrypted meetings, per-meeting encryption keys must be generated and distributed to the meeting owner’s client without becoming a synchronous bottleneck. This is handled by a dedicated, horizontally-scaled key management service that pre-generates key material in bulk during low-traffic windows and hands out pre-generated keys during surges rather than computing them on demand.

9.5 Compliance and Audit Logging Under Load

Regulated customers (financial services, healthcare, government) often require that every meeting-creation event be captured in an immutable audit log for compliance purposes. Writing audit records synchronously on the fast path would reintroduce exactly the kind of blocking dependency this design works to eliminate. Instead, audit logging is treated as a guaranteed-delivery, at-least-once consumer of the same “MeetingCreated” Kafka event used for other async work, with the audit log’s completeness tracked independently and reconciled against the source-of-truth database on a short delay (typically under a few seconds) rather than requiring the audit write to complete before the user gets a response. Deduplication on the audit consumer side (keyed by meeting ID) handles the at-least-once delivery semantics safely.

Observability for surge-shaped load has to answer a specific question: is the system tracking above or below its forecast right now, and by how much?

10.1 Key Metrics to Track

10.2 Distributed Tracing

Every meeting-creation request is tagged with a trace ID propagated across the API gateway, MCS, ID generator, room allocation, and database calls. During a surge, distributed tracing (e.g., OpenTelemetry-based) is essential for quickly identifying which specific downstream hop is contributing most to tail latency, rather than guessing from aggregate dashboards alone.

10.3 Alerting Philosophy

• Alert on leading indicators (queue depth growth rate, replication lag trend) rather than only lagging indicators (error rate), since leading indicators give on-call engineers minutes of lead time before user impact.
• Use anomaly-aware alerting that understands the expected daily surge pattern, so the 9 AM spike itself doesn’t trigger false-positive pages every single day.
• Maintain a real-time “surge dashboard” per region showing current load against predicted load, so on-call engineers can immediately see if a region is tracking above or below its forecast.

10.4 Post-Surge Review Loop

After each daily surge window, an automated post-surge report compares predicted load against actual observed load, per region, and flags regions where the deviation exceeded a defined threshold (for example, more than 15% above or below prediction). This feeds directly back into recalibrating the predictive scaling model, closing the loop between observability and capacity planning rather than treating them as separate disciplines. Over time, this turns the predictive model from a static, manually-tuned artifact into a continuously self-correcting system that improves its own forecasts as the user base and their behavior evolve.

Where the compute physically lives and how it’s rolled out matters as much as how the code is written — especially when the surge and a bad deploy can collide in the same fifteen-minute window.

11.1 Multi-Region, Multi-AZ Deployment

Compute for the fast-path services (API gateway, MCS, ID generator, room allocation) is deployed across multiple availability zones within each region, behind regional load balancers, with predictive pre-scaling applied per-region ahead of each timezone’s local morning peak.

11.2 Container Orchestration and Fast Scale-Out

Kubernetes (or an equivalent orchestrator) manages the API and worker fleets. Because container cold-start time itself contributes to scale-up lag, a warm pool of pre-provisioned but idle pod replicas is maintained just below the predicted peak, ready to receive traffic instantly rather than needing to schedule new pods from zero during the surge itself.

11.3 CI/CD and Deployment Freezes

Deployments of the meeting-creation fast path are automatically blocked during each region’s predicted surge window via deployment freeze windows tied to the same timezone-aware calendar that drives predictive scaling — a rollout or canary deployment is one of the highest-risk activities to perform exactly when the system has the least slack to absorb an issue.

11.4 Cost Optimization

• Spot/preemptible instances for the async worker pools (calendar sync, analytics), which can tolerate interruption and restart, are used to reduce cost for the bulk of the compute footprint.
• Reserved/committed capacity is used for baseline fast-path compute, with on-demand and pre-warmed autoscaling covering the predictable surge delta.
• Follow-the-sun capacity reuse: Because the surge is timezone-staggered, compute capacity pre-warmed for the Asia-Pacific morning surge can, in principle, be partially reused (via regional rebalancing) for the European surge hours later — though in practice this requires careful capacity-pool design since most cloud providers charge per-region.

11.5 Multi-Cloud and Vendor Considerations

Some large conferencing providers deliberately spread capacity across more than one cloud provider or a mix of cloud and owned data-center capacity, partly for negotiating leverage and partly as an additional layer of resilience against a single provider’s regional outage coinciding with a local surge window. This adds meaningful operational complexity — consistent deployment tooling, network peering, and data residency handling all need to work uniformly across providers — and is generally only justified once scale is large enough that the redundancy benefit outweighs the added complexity; a system in early growth stages is usually better served by deep investment in multi-region resilience within a single cloud provider first.

The data layer is where a surge either lives or dies. Sharding, caching, and stampede prevention all need to be designed for the specific correlated-burst shape of morning-peak traffic.

12.1 Sharding Strategy

Sharding by organization ID keeps all of a given company’s meetings co-located, which simplifies most real-world query patterns (an org’s admin dashboard, billing rollups) while spreading write load across shards during the surge, since different organizations’ employees are creating meetings independently and roughly in parallel. The main risk is hotspotting from disproportionately large organizations, mitigated by sub-sharding very large tenants across multiple shard partitions with a secondary hash.

12.2 Caching Strategy

12.3 Preventing Cache Stampede

When a cache entry (e.g., an organization’s quota counter) expires under heavy concurrent load, naive caching causes a stampede of requests all hitting the database simultaneously to repopulate it. The system mitigates this with request coalescing (only one in-flight request repopulates the cache while others wait on that result) and staggered TTL jitter, so cache entries for different keys don’t all expire in the same instant during the surge.

12.4 Load Balancing Approach

• L4 (transport layer): Used at the outer edge for raw connection distribution with minimal overhead.
• L7 (application layer): Used at the API gateway for content-aware routing — e.g., routing meeting-creation traffic separately from media/signaling traffic, so a spike in one doesn’t starve the other.
• Consistent hashing is used for shard routing to minimize re-distribution churn when shards are added during capacity expansions.

12.5 Handling Hot Shards from Very Large Organizations

Even with a well-chosen shard key, a single very large enterprise customer with tens of thousands of employees all starting their workday at the same local time can create a hotspot on the shard holding that organization’s data, since sharding by organization ID inherently keeps that org’s writes concentrated on one partition. The mitigation is a secondary, org-aware sub-sharding scheme applied only above a configurable size threshold: organizations beyond that threshold have their meeting records further hash-partitioned across multiple physical shards, with a lightweight lookup layer (cached aggressively, since it changes rarely) mapping an organization to its set of sub-shards. Smaller organizations, which make up the vast majority of tenants, remain on the simpler single-shard-per-org model, keeping the common case simple while still solving the tail case that would otherwise dominate capacity planning.

The fast-path / slow-path split isn’t just an internal architecture — it’s baked into the API contract itself, and into how services talk to each other.

13.1 API Design

The meeting-creation API is designed to be minimal and fast by contract:

• POST /v1/meetings — accepts owner ID, org ID, optional settings, and a client-generated idempotency key; returns meeting ID and join URL synchronously.
• PATCH /v1/meetings/{id}/settings — a separate, non-blocking endpoint for enriching meeting settings (recording preferences, waiting room config) after the core meeting exists, so the client can update the UI progressively without blocking the initial creation response.

This split — a minimal synchronous creation call plus asynchronous enrichment calls — is itself an application of the fast-path/slow-path principle at the API contract level, not just internally.

13.2 Microservice Boundaries

Each service in the fast path owns a narrow, well-defined responsibility and communicates via well-versioned APIs and events, never sharing a database directly with another service. This enforces the bulkhead principle at the architectural level: a schema change or performance regression in the calendar-sync service cannot directly break the meeting-creation service, because they don’t share storage.

13.3 Backpressure Between Services

The Meeting Creation Service applies explicit backpressure to its own callers (the API gateway) when its downstream Kafka producer buffer approaches capacity, returning a fast 429/503 with a Retry-After hint rather than allowing unbounded in-memory queuing that would eventually cause an out-of-memory crash — a classic and avoidable cause of full outages during a surge.

13.4 Service Mesh Considerations

At the scale of tens of thousands of requests per second fanning out across a dozen or more internal services, a service mesh (such as a sidecar-proxy-based mesh) provides consistent mutual TLS, retry policy, timeout enforcement, and traffic-shaping configuration without requiring every individual service team to reimplement this logic. During a surge, the mesh’s centrally-configured retry budgets are particularly important: without a shared retry budget, several services independently retrying failed calls to an already-struggling downstream dependency can multiply the effective load on that dependency far beyond what any single service’s retry policy intended, turning a minor slowdown into a full outage through uncoordinated retry amplification. A mesh-level retry budget caps the total retry volume across all callers to a shared ceiling, which is very difficult to achieve consistently through per-service configuration alone.

The design leans on a small, well-worn set of patterns — and pointedly avoids a handful of anti-patterns that convert a manageable surge into a full outage.

14.1 Patterns Applied

14.2 Anti-Patterns to Avoid

A distilled operational checklist for teams building or operating this kind of system — and the mistakes that most reliably show up in post-mortems.

Publicly-discussed practices from major conferencing providers that map, at a high level, to the ideas in this document.

Questions that repeatedly come up when engineers first encounter this design, answered directly.

Why not simply over-provision enough capacity to handle peak load all the time?

The surge lasts roughly 15–20 minutes per timezone out of 24 hours. Provisioning full peak capacity permanently across every region would mean paying for compute that sits over 95% idle most of the day — an enormous and unnecessary cost. Predictive pre-scaling captures most of the latency benefit at a fraction of the cost.

How is this different from a classic “thundering herd” cache problem?

A classic thundering herd is usually triggered by a single system event (a cache key expiring) and can often be fixed with request coalescing alone. A timezone-driven meeting surge is triggered by correlated human behavior across millions of independent users and requires system-wide capacity, admission control, and architectural changes, not just a caching fix.

What happens if the predictive scaling model gets the surge timing or magnitude wrong?

The reactive auto-scaler and the graceful degradation ladder act as safety nets — the system will still scale out (with some added latency) and will degrade non-critical features before rejecting core meeting creation, so an imperfect prediction causes a temporary latency increase rather than an outage.

Why use Kafka (or similar) instead of a simple message queue like a basic FIFO queue service?

Kafka’s durable, replicated log model allows multiple independent consumer groups (calendar sync, notifications, analytics) to each process the same event stream at their own pace without competing for or duplicating messages, and it retains data long enough to allow slow consumers to catch up after a surge without data loss.

Does end-to-end encryption complicate surge handling?

It adds one more resource (key material) that must be pre-generated and readily available rather than computed on demand during the surge, but doesn’t fundamentally change the overall fast-path/slow-path architecture.

How would this design change for a startup that can’t afford multi-region, predictive-scaling infrastructure yet?

The core, cheapest-to-implement principles — idempotent writes, an async queue for non-critical work, and a simple reactive auto-scaler with a generous headroom buffer — capture most of the resilience benefit at a fraction of the engineering cost. Multi-region active-active deployment and a fully-tuned predictive scaling model are refinements worth adding once traffic and revenue justify the added operational complexity, not prerequisites for handling a first surge safely.

How do you avoid the predictive scaling model itself becoming a single point of failure?

The predictive controller only ever issues scale-out recommendations that get layered on top of the reactive auto-scaler’s independent decisions; if the predictive service is unavailable, the system simply falls back to purely reactive scaling with a slightly higher risk of transient latency during the surge, rather than losing the ability to scale at all.

Zoomed back out, the entire design is really a bet on discipline: predict what you can, absorb what you can’t, and never let the slow path drag the fast path down.

Read this system back at the highest level and it is really a bet on discipline: predict what you can, absorb what you can’t, and never let the slow path drag the fast path down. Almost every serious real-world implementation of correlated-burst infrastructure — video conferencing, ticketing, streaming prime-time, tax-filing deadlines — ends up rediscovering the same shape, because the underlying constraint (a wall of humans acting on a shared clock) does not leave much room for anything more clever.