🇨🇳 中文版 ｜ 📦 GitHub: https://github.com/geekchow/aws-lambda-guideWhere you are:Stage 4 of 6 (Running example).After this file you will know:the one scenario every later file refers back to, and which component is on stage at each step — still without internals.The scenario in three sentencesOnThursday 2026-11-26, ShopFast’s team ships coupon support asversion 8of thecheckoutfunction, shifting theprodaliasfrom v7 to v8 by canary (10% for 10 minutes, then 100%).Before the sale opens onFriday 09:00, they raiseprovisioned concurrencyonprodfrom 50 to 400 so the first wave of shoppers never sees a cold start.At 09:05 a viral post pushes traffic beyond the warm pool: extra requestsspill overto cold on-demand environments, and at the very top a few arethrottledby the function’s reserved concurrency cap.The cast (fixed facts used everywhere)ItemValueAccount / Region111122223333/us-east-1Functioncheckout, Node.js 22 runtime, 1,024 MB memory, 10 s timeoutCallerAPI (Application Programming Interface) Gateway REST API, integration ARN (Amazon Resource Name)arn:aws:lambda:us-east-1:111122223333:function:checkout:prodVersionsv7 (current), v8 (new, coupons)Aliasprod→ v7, PC (Provisioned Concurrency) = 50Reserved concurrency800 (socheckoutcan never starve other functions, nor be starved)Average duration150 ms warm; cold Init ≈ 600 msAccount concurrency quota3,000Three named requests we follow:RequestWhenFateAlice’s checkoutThu 14:05, during the canaryLands on v8 (the 10%), served by a warm PC environmentBob’s checkoutFri 09:05, the viral spikePC pool full → spillover → cold start on a new v8 environmentCarol’s checkoutFri 09:06, the very peakReserved concurrency of 800 reached →429throttle; API Gateway returns an error, the client retriesThe scenario traced shallowlyQuestion it answers: in what order do the players appear across the week?Friday: the sale08:30 Auto Scaling setsPC to 400Placement boots 400v8 envs, Init runs09:00 2,000 RPS,300 concurrent: all warm09:05 Bob: PC full,spillover cold start09:06 Carol: 800 cap hit,429 throttleThursday: deployCI updates code of$LATESTVersion store publishesv8Alias prod becomesv7 90 / v8 10PC manager splits warmpool across v7 and v8Alice request routedto v8, warm envAlarms quiet:prod = v8 100Caption: the week in ten steps — the spine every depth dive anchors to.Thursday — deploying v8(T1–T2)The CI/CD (Continuous Integration / Continuous Delivery) pipeline uploads the new zip to thefunction’s$LATEST, then callsPublishVersion. TheVersion storefreezes code + config asversion 8.(T3)CodeDeploy updates thealiasprod: primary v7, additional version v8 with weight 0.10. API Gateway’s integration still sayscheckout:prod— nothing on the caller side changes.(T4)Becauseprovisioned concurrencyis configured onprod, thePC managernow keeps warm environments forbothversions, roughly in proportion to the weights.(T5)Aliceclicks “Pay”. API Gateway invokescheckout:prod. TheInvoke Frontendauthenticates the call, thealias routerrolls the weighted dice → v8. TheCounting serviceconfirmscheckoutis under its limits. TheAssignment servicefinds an idle, pre-initialized v8execution environmentand the handler runs in ~150 ms. No cold start.(T6)Ten quiet minutes later CodeDeploy setsprod→ v8 at 100%. (Had errors spiked, it would have set the weight back to 0 — a rollback in seconds.)Friday — the sale(F1–F2)At 08:30 a scheduled action inApplication Auto Scalingraises PC onprodto 400. ThePC managerasksPlacementfor 400 v8 environments; each runs itsInitphase now, not during a request.(F3)At 09:00, 2,000 RPS (Requests Per Second) × 0.15 s ≈300 concurrentinvocations. Every one lands on a warm PC environment.(F4)At 09:05 traffic jumps to ~4,500 RPS → ~675 needed. The 400 PC environments are busy;Bob’s request is admitted by Counting (675 < 800) but the Assignment service has no idle environment, soPlacementcreates a new on-demand v8 environment. Bob waits ~600 ms extra: acold start(aspilloverinvocation).(F5)At 09:06 demand briefly needs ~850.Carol’s request is the 801st concurrent one; theCounting servicerejects it with429.What each step touchesConcept / playerStepsFunction /$LATEST1Version (Version store)1, and every later step runs “v8”Alias (alias router)2, 4, 5Provisioned concurrency (PC manager + Auto Scaling)3, 6, 7, 8Invocation & concurrency (Frontend + Counting)4, 7, 8, 9Assignment + Placement4, 6, 8Execution environment4, 6, 7, 8Test yourself:without scrolling up, who rejects Carol, and why isn’t that the PC manager’s job? (Answer: the Counting service, because PC never caps traffic — it only pre-warms.)Next →05.1 Versions ·Back to03 Concept map📚 Back to series index
🇨🇳 中文版 ｜ 📦 GitHub: https://github.com/geekchow/aws-lambda-guideWhere you are:Stage 4 of 6 (Running example).After this file you will know:the one scenario every later file refers back to, and which component is on stage at each step — still without internals.The scenario in three sentencesOnThursday 2026-11-26, ShopFast’s team ships coupon support asversion 8of thecheckoutfunction, shifting theprodaliasfrom v7 to v8 by canary (10% for 10 minutes, then 100%).Before the sale opens onFriday 09:00, they raiseprovisioned concurrencyonprodfrom 50 to 400 so the first wave of shoppers never sees a cold start.At 09:05 a viral post pushes traffic beyond the warm pool: extra requestsspill overto cold on-demand environments, and at the very top a few arethrottledby the function’s reserved concurrency cap.The cast (fixed facts used everywhere)ItemValueAccount / Region111122223333/us-east-1Functioncheckout, Node.js 22 runtime, 1,024 MB memory, 10 s timeoutCallerAPI (Application Programming Interface) Gateway REST API, integration ARN (Amazon Resource Name)arn:aws:lambda:us-east-1:111122223333:function:checkout:prodVersionsv7 (current), v8 (new, coupons)Aliasprod→ v7, PC (Provisioned Concurrency) = 50Reserved concurrency800 (socheckoutcan never starve other functions, nor be starved)Average duration150 ms warm; cold Init ≈ 600 msAccount concurrency quota3,000Three named requests we follow:RequestWhenFateAlice’s checkoutThu 14:05, during the canaryLands on v8 (the 10%), served by a warm PC environmentBob’s checkoutFri 09:05, the viral spikePC pool full → spillover → cold start on a new v8 environmentCarol’s checkoutFri 09:06, the very peakReserved concurrency of 800 reached →429throttle; API Gateway returns an error, the client retriesThe scenario traced shallowlyQuestion it answers: in what order do the players appear across the week?Friday: the sale08:30 Auto Scaling setsPC to 400Placement boots 400v8 envs, Init runs09:00 2,000 RPS,300 concurrent: all warm09:05 Bob: PC full,spillover cold start09:06 Carol: 800 cap hit,429 throttleThursday: deployCI updates code of$LATESTVersion store publishesv8Alias prod becomesv7 90 / v8 10PC manager splits warmpool across v7 and v8Alice request routedto v8, warm envAlarms quiet:prod = v8 100Caption: the week in ten steps — the spine every depth dive anchors to.Thursday — deploying v8(T1–T2)The CI/CD (Continuous Integration / Continuous Delivery) pipeline uploads the new zip to thefunction’s$LATEST, then callsPublishVersion. TheVersion storefreezes code + config asversion 8.(T3)CodeDeploy updates thealiasprod: primary v7, additional version v8 with weight 0.10. API Gateway’s integration still sayscheckout:prod— nothing on the caller side changes.(T4)Becauseprovisioned concurrencyis configured onprod, thePC managernow keeps warm environments forbothversions, roughly in proportion to the weights.(T5)Aliceclicks “Pay”. API Gateway invokescheckout:prod. TheInvoke Frontendauthenticates the call, thealias routerrolls the weighted dice → v8. TheCounting serviceconfirmscheckoutis under its limits. TheAssignment servicefinds an idle, pre-initialized v8execution environmentand the handler runs in ~150 ms. No cold start.(T6)Ten quiet minutes later CodeDeploy setsprod→ v8 at 100%. (Had errors spiked, it would have set the weight back to 0 — a rollback in seconds.)Friday — the sale(F1–F2)At 08:30 a scheduled action inApplication Auto Scalingraises PC onprodto 400. ThePC managerasksPlacementfor 400 v8 environments; each runs itsInitphase now, not during a request.(F3)At 09:00, 2,000 RPS (Requests Per Second) × 0.15 s ≈300 concurrentinvocations. Every one lands on a warm PC environment.(F4)At 09:05 traffic jumps to ~4,500 RPS → ~675 needed. The 400 PC environments are busy;Bob’s request is admitted by Counting (675 < 800) but the Assignment service has no idle environment, soPlacementcreates a new on-demand v8 environment. Bob waits ~600 ms extra: acold start(aspilloverinvocation).(F5)At 09:06 demand briefly needs ~850.Carol’s request is the 801st concurrent one; theCounting servicerejects it with429.What each step touchesConcept / playerStepsFunction /$LATEST1Version (Version store)1, and every later step runs “v8”Alias (alias router)2, 4, 5Provisioned concurrency (PC manager + Auto Scaling)3, 6, 7, 8Invocation & concurrency (Frontend + Counting)4, 7, 8, 9Assignment + Placement4, 6, 8Execution environment4, 6, 7, 8Test yourself:without scrolling up, who rejects Carol, and why isn’t that the PC manager’s job? (Answer: the Counting service, because PC never caps traffic — it only pre-warms.)Next →05.1 Versions ·Back to03 Concept map📚 Back to series index