Outcome
By the end of this lesson, you will be able to distinguish Event Readiness from reactive autoscaling, identify which events warrant pre-scaling, and recognize when the 5-minute ramp-up gap matters.
| Tier | Engineer |
| JTBD | ”Pre-scale infrastructure for predictable traffic events: eliminate the autoscaler ramp-up gap that costs customers latency during peaks.” |
| Personas | Platform Engineer · SRE · Site Reliability |
| Prerequisites | M2.4 (VM autoscaling) |
| Time | 9 minutes |
| Bloom verb | Distinguish (Analyze), Identify (Apply), Recognize (Apply) |
1. Concept
Ordinary autoscaling waits for the traffic, then adds capacity. That is the right design for traffic you did not see coming.
It is the wrong design for Black Friday. You know the date. You know roughly what is coming. Waiting for it to arrive means the first few minutes of your biggest day are served by a system that is still catching up, and the customers in those minutes are the ones who notice.
Event Readiness scales up in advance, so the capacity is already there when the traffic is.
THE PROBLEM: Reactive autoscaling has a 5-minute lag During lag: capacity saturated; customers feel pain
For unpredictable events: no choice but reactive For PREDICTABLE events: we can do better
THE SOLUTION: Define the event in ZopNight Pre-scale BEFORE the event start Run at event capacity through the event Scale back after
Zero ramp-up gap; smooth customer experienceThe trade-off is cost (pre-scaled capacity costs money before traffic arrives).
The reactive autoscaling problem
TIMELINE during Black Friday (reactive only):
T+0 Traffic starts ramping upT+0 Existing capacity: 12 instancesT+1 min CPU hits 80% (autoscaler trigger threshold)T+1 min Autoscaler triggers scale-outT+1 min 3 new instances launchingT+3 min New instances reaching ready stateT+5 min New instances healthy and servingT+5 min Capacity catches up to traffic
DURING T+0 to T+5 min window: Existing capacity (12 instances) at 100%+ CPU P99 latency spikes 3-5x Some users see degraded experience Possibly: some traffic dropped or queued
COST OF THE 5-MIN GAP: Lost orders (some customers bounce) Latency-correlated lower conversions Bad customer reviews / support tickets Brand impact for high-profile eventsThe 5-minute gap is the problem. Event Readiness eliminates it.
How Event Readiness works
PHASE 1: PRE-EVENT (days before) Define the event in ZopNight: date, scope, expected multiplier ZopNight calculates capacity needs Customer reviews + approves
PHASE 2: EVENT START (e.g., 1 hour before peak traffic) ZopNight pre-scales the infrastructure: Increases ASG min/max Pre-warms instance pools Scales databases (monitor-only: see L4) Pre-warm completes BEFORE traffic arrives
PHASE 3: EVENT DURATION (event period) Infrastructure is at event capacity Traffic arrives; no ramp-up gap Performance stays smooth
PHASE 4: EVENT END (e.g., 1 hour after expected peak) ZopNight scales back down to normal Cost returns to baseline Audit log captures the full lifecycleThe event window is treated as a special schedule: pre-warm, run at capacity, scale back.
What gets pre-scaled
TARGETS THAT GET PRE-SCALED (automatic): ASG (AWS): scale_out to event capacity ECS service: desired_count to event capacity GCP MIG: target_size to event capacity Azure VMSS: capacity to event capacity Lambda concurrency: provisioned concurrency increased Instance pools: pre-warm to event capacity
TARGETS THAT ARE MONITORED-ONLY (see L4): Databases (RDS, Cosmos, etc.): No automated mutation Recommendations surface for customer to act manually Customer scales DB on their own (because data risk)The asymmetry is intentional: compute is auto-scaled; data is human-scaled. (Recall M2.3.L5: database denylist.)
Event Readiness vs scheduling
SCHEDULING EVENT READINESS─────────────────────────────────────────────────────────Recurring (daily, weekly) One-time eventCron-driven Datetime-driven (event start/end)Stops at end (off-hours) Scales back at end (resume normal)For non-prod For prod traffic eventsSaves money Costs money temporarilyOff → On Normal → Higher → NormalThe two layers complement. Most teams have both: schedules for non-prod, Event Readiness for one-off events.
When Event Readiness matters
EVENT TYPE USE EVENT READINESS?─────────────────────────────────────────────────────Product launch YES: large predictable spikeBlack Friday YES: predictable annual spikeMarketing email blast YES: known time, known multiplierNewsletter send YES: small but known burstLoad test YES: for the test durationGeo-rollout YES: predictable per-region spikeTV ad spot YES: known timingConference / event broadcast YES: known traffic windowRandom viral moment NO (can't predict; reactive autoscale)Daily peak hours NO (use Peak Hours preset)Steady traffic growth NO (autoscaler handles)The principle: Event Readiness wins when the event is predictable.
Cost of Event Readiness
EXAMPLE: Black Friday event for 24 hours Normal capacity: 12 instances ($24/day) Event capacity: 36 instances ($72/day) Cost during event: $72 (3x normal) Cost above baseline: $48
Total cost of pre-scaling: $48 Plus 1 hour pre-warm: $4 Plus 1 hour buffer scale-down: $4 Total event cost: $56
VALUE: Lost orders prevented: typically $50K-$500K Customer experience preserved: priceless Brand impact avoided: significant
ROI: usually >100x for major eventsThe cost is real but small relative to the value.
Cost monitoring during event
ZopNight provides: Live cost tracker during event Estimated remaining event cost Comparison to baseline Recommendations for adjustments
EXAMPLE during event: Current spend rate: $72/hr (vs $24/hr baseline) Estimated event total: $1,728 (24 hours) Time remaining: 6 hours
If traffic lower than expected: can scale back early If traffic higher: can scale up Real-time adaptationThe cost transparency during the event allows mid-event tuning.
2. Demo
A team’s Black Friday preparation:
EVENT: Black Friday 2026SCOPE: production checkout service + product API + database tier
PLANNING (October: 5 weeks ahead): Define event in ZopNight: Date: November 28, 00:00 - 23:59 UTC Scope: production-prod-checkout group + production-prod-api group Expected multiplier: 3x normal capacity Pre-warm: 1 hour Scale-down buffer: 1 hour
CAPACITY CALCULATION: Current capacity: 12 instances Expected: 36 instances (3x) Adjustment: round up to 40 for buffer
COST ESTIMATE: ZopNight quotes $4,200 additional for the 24-hour event window Customer approves
NOVEMBER 27 23:00 UTC (1 hour before event): ZopNight pre-scales: ASG-checkout: scale to 40 instances ASG-api: scale to 60 instances Pre-warm 40 + 60 = 100 instances over ~10 minutes Database tier: monitored-only; team adjusted manually beforehand
NOVEMBER 28 00:00 - 23:59 UTC (event): Traffic arrives P99 latency: 110ms (normal) Capacity utilization: 75% (healthy) No degradation during traffic ramp Conversion rate: stayed at expected level
NOVEMBER 28 23:59 UTC (event ends): Autoscaler scales back to baseline Cost returns to normal Audit log captures full lifecycle
RESULT: $4,200 spent on pre-scaling ~$300K of customer orders processed without issues Customer experience: smooth Engineering team: confident ROI: 70:1Pre-scaling cost is real but worth it for the customer experience.
3. Hands-on (5 min)
Plan a hypothetical event:
□ STEP 1: Identify upcoming event Event: __________ Date: __________ Duration: __________
□ STEP 2: Estimate traffic multiplier Normal traffic: __________ Expected event traffic: __________ Multiplier: ___x
□ STEP 3: Identify scope Affected workloads: __________ Database tier: __________
□ STEP 4: Calculate capacity needs Current capacity: __________ Event capacity needed: __________ Buffer: __________
□ STEP 5: Estimate cost Normal cost: $_____ Event cost: $_____ Additional cost: $_____ Estimated value of preventing latency spike: $_____A 20-minute exercise reveals the math. Most events: ROI strongly favors pre-scaling.
4. Knowledge check
Q1
Reactive autoscaling vs Event Readiness:
A. Same thing
B. Different cloud providers
C. Event Readiness is reactive as well, only rather slower to act on it
D. Reactive triggers after traffic hits the saturation threshold (5-min lag)
Show answer
Correct: D. Event Readiness pre-scales before. Use both: reactive for unexpected, Event Readiness for known events. Complementary, not competing. Complementary.
Q2
A team has a marketing launch in 3 weeks. The right approach:
A. Trust reactive autoscaling
B. Manual escalation
C. Use Event Readiness; define the event, pre-scale 1 hour before, scale back 1 hour after
D. Pre-scale absolutely everything by hand on the morning of the launch day itself
Show answer
Correct: C. Eliminates the 5-minute ramp-up gap for known events. Predictable events warrant pre-scaling. Predictable events warrant Event Readiness.
Q3
A viral moment causes unexpected traffic. Best approach:
A. Event Readiness (define event)
B. Reactive autoscaling: viral events are by definition unpredictable
C. Define an event retroactively so as to cover it afterwards
D. Manual
Show answer
Correct: B. Event Readiness can’t pre-schedule. The 5-min lag is unavoidable but rare. Reactive handles unpredictable.
5. Apply
Event Readiness at Automation → Event Readiness. Define events, calculate capacity, approve, schedule.
For your team: identify upcoming predictable events; use Event Readiness for them.
Related lessons
- L2: Capacity models (next)
- L3: Lifecycle
- L4: Database monitor-only
- L5: Cost estimate
- M2.4: VM autoscaling
Glossary terms touched
Event Readiness · Reactive autoscaling gap · Pre-scaling · Predictable event