Elasticity

Definitions That Get Confused

 SCALABILITY: CAN the system handle more load?
              (a ceiling — architectural property)

 ELASTICITY:  How FAST and SMOOTHLY does capacity track demand?
              (a response behavior — operational property)
 
 ELASTIC system: load doubles → capacity doubles in minutes,
                 cost follows usage; load drops → shrink back.
 SCALABLE but RIGID: can serve 100x... after a week of provisioning.

A system can scale to millions of users yet be perfectly inelastic — sharded across fixed hardware, resized quarterly. Cloud-native systems chase both.

What Elasticity Requires

 1. HORIZONTAL architecture    capacity = node count (additive units)
 2. STATELESSNESS at the tier  new nodes usable immediately
 3. FAST PROVISIONING          images small, boots quick, config injected
 4. AUTOMATED TRIGGERS         metrics → decisions without humans
 5. DEMAND-SHAPED STORAGE      storage that grows without migration
 
 missing any one → "autoscaling" exists but elasticity doesn't:
 pods start in seconds yet wait 10 min on a DB migration
 = a rigid system wearing elastic clothes

The Response Curve

 demand ──────────►
                    ╭──────╮
 capacity ────────► │      ╰──╮
              ╭─────╯          ╰──
        ▲    ▲
        │    └─ catch-up gap: unserved/degraded minutes
        └─ reaction delay: detect + decide + boot

 shrinking that gap:
   predictive/scheduled scaling for KNOWN patterns
   faster signals (queue depth beats cpu) 
   pre-baked warm pools for violent spikes

The catch-up gap is where incidents live: viral moments and launches fail not because ceilings were low, but because walls arrived before capacity did.

Cost: The Real Payoff

 diurnal traffic typically varies 3–5x between night and peak.

 static provisioning: pay peak price, 24h/day
 elastic provisioning: track the curve; pay ≈ integral of demand

 typical savings 40–60% on stateless tiers —
 elasticity is as much a FINANCE feature as a reliability one.
 (spot/preemptible capacity compounds it further for batch work.)

Elasticity Boundaries

Component	Elastic?	Why
Stateless APIs	✓	The textbook case
Queue consumers	✓✓	Backlog is a perfect signal
Caches	⚠	Resharding on scale events loses warmth
Databases	✗ mostly	Data placement isn’t additive
Serverless functions	✓ by construction	Platform handles the curve

The database row explains serverless architectures’ appeal: push ALL elasticity-sensitive work into functions + managed stores; keep only thin stateless glue.

Interview Framing

Use the words distinctly: “the design is scalable to X because of sharding, and elastic day-to-day via autoscaling on queue depth with scheduled pre-warm for known peaks.” Naming the catch-up gap strategy for launch/viral scenarios (“pre-provision, then relax”) reads as someone who has been paged during one.