भाग 5: मापो, बदलो, फिर मापो: Load Test, Real Exam Night और Final Architecture

7 अक्टूबर की शाम को, 661 विद्यार्थी NovaCommerce पर एक exam शुरू करते थे, peak 86 start एक मिनट में, और 439 और एक दूसरे exam के बाद बैठे। Backend लगभग 69 requests per second को peaked और 47% CPU पर दो-minute average reach किया। Database अपने 25% से कम CPU use किया। कोई भी background job failed नहीं हुआ।

फिर एक pool minimum को exam के बीच lower किया गया। एक serving node बिना drain के vanish किया, और लगभग 360 request 2 मिनट में fail हुए।

शाम के दोनों half test result थे: calm half कुछ दिनों पहले test का एक short run से आया, ugly half कुछ से आया कोई test अभी तक cover किया नहीं। यह part journey को order में walk करता है (baseline, load test, bottleneck, optimization, retest, scaling, soak, final result), फिर final architecture, इसकी cost, और checklist जो मैं अब हर review में use करता हूँ दिखाता है।

यह "From One Server to Exam-Day Ready" five-part case study का हिस्सा 5 है। NovaCommerce एक काल्पनिक नाम है; architecture, संख्याएँ और गलतियाँ वास्तविक हैं।

Loop जो हमने बार-बार रखा

हर change इस series में एक loop से आया: measure, bottleneck ढूँढो, कारण को समझो, design change करो, फिर से test करो, फिर से measure करो। Change guess से पहले कारण को समझा एक guess है, और एक guess जो server होना आता है हर महीना खर्च करता है। एक garden hose की तरह एक kink के साथ सोचो: अगर पानी weak है, एक बड़ा tap कुछ नहीं करता, तो आप hose के साथ चलते जब तक आप kink नहीं पाते। हमारा तीन बार moved, और हर बार यह एक अलग problem kind था।

Baseline और load test: bottleneck तीन बार moved

Baseline: CPU graph नहीं, status code

पहली चीज़ जो हमने measure किया production पर CPU नहीं था। 25 सितंबर पर, विद्यार्थियों को exams के दौरान HTTP 429 (बहुत ज़्यादा request) मिल रहे थे। API rate limiter IP address से keyed था, क्योंकि default auth guard token-based विद्यार्थी के लिए empty था। एक school या एक mobile carrier सैकड़ों विद्यार्थियों को एक NAT IP के पीछे रखता है, तो एक पूरी building एक bucket share करती है। 429 application कह रहा है "no", सर्वर breath नहीं का, तो कोई extra node could have helped नहीं। Implemented: limiter अब विद्यार्थी या instructor account से key करता है, और IP से सिर्फ़ guest के लिए।

Load test: 2,854 error, एक sentence

6 अक्टूबर को 02:28 पर, एक backend load test 2,854 application 500 दे गया, हर एक RedisException: Operation timed out connecting के दौरान (5-second connect timeout)। Cause: Valkey (4 GB, primary और standby) connection को fast enough accept नहीं कर सकता, और हर request Valkey को fresh TLS connection खोलता, लगभग 5.4 ms CPU per request MySQL के लिए लगभग 3.3 ms के विरुद्ध। ज़्यादा web node सिर्फ़ same Valkey में ज़्यादा connection खोलते।

Implemented: Valkey in place resize किया 8 GB को दो node (primary और standby) में, data kept, host unchanged। यह ज़्यादा पैसे cost करता है, और real failure remove किया।

Retest: 25 से 500 requests per second तक एक gradual climb, 2 backend node पर शुरू करते हुए pool scale out, 0 application error और 0 backend 5xx दिए। Load balancer पर 143 error थे, लेकिन सिर्फ़ जबकि node saturated CPU पर थे। यह expected "out of capacity" signal है, bug नहीं, और यह हमें दिखाता था जहाँ हर node run out करता है।

एक node कितना कर सकता है

Backend test भी हमें number दिया जिस पर हर बाद decision lean करता है। Full CPU पर, एक 4 vCPU / 8 GB backend node lगभग 65 to 70 requests per second के real API mix को serve किया, लगभग 59 ms CPU per request। Figure agree: 4 vCPU 4,000 ms CPU per second है, और 4,000 59 से divide लगभग 68 है। Autoscale पहला extra node लगभग 7 मिनट बाद add किया CPU 99% hit करने के।

यह तीन bottleneck एक order में दिखाता है: rule (limiter), data tier (Valkey connection), और सिर्फ़ फिर plain backend CPU। हर एक अलग fix की जरूरत, और सिर्फ़ अंतिम ज़्यादा server से solve होता।

Scaling test: नए server arrive करते हैं, और कब?

Frontend: दो node, 356 requests per second

Frontend rebuild एक pool के रूप में (nginx front में दो identical Next.js container per node), दो node लगभग 356 requests per second, p95 0.05 s, 0 error, 55 to 60% CPU पर, और हमने 12 real page पुराने server के विरुद्ध compare किए। Headroom paid for itself: pool dedicated-CPU droplet से shared AMD 2 vCPU / 4 GB droplet में moved। Implemented।

16-minute autoscale test

5 अक्टूबर पर, 21:17 से 21:33 तक, k6 ने real exam-peak request mix replay किया (सिर्फ़ GET, कुछ नहीं written): 300 to 450 requests per second, फिर लगभग 750 छह मिनट के लिए।

• Backend 21:29 पर 2 से 3 node scale, जब pool average 75% तक reach किया। Frontend 21:30 पर 2 से 3 scaled, 71% पर। नए node load balancer में अपने आप joined।
• 0 server error, 0 timeout, 132 से 153 ms overall p95। Backend 90% के पास बैठा जबकि तीसरा node wait किया जब API p95 320 to 705 ms था।
• लगभग 4% request को 429 मिला, क्योंकि सब load एक test IP से आया: per-IP limit अपना काम कर रहे थे।

Lesson timing में था। DigitalOcean का CPU metric 5 to 8 मिनट real load से lag करता है, तो scaling शुरू होता late और फिर overshoot करता: backend briefly 4 के लिए scale किया load stop होने के बाद। Test शुरू से पहला extra backend node बारह मिनट बाद आया, और exam एक minute का wait नहीं करता। तो scheduled exam के लिए हमारे पास pool minimum को लगभग 45 मिनट raise पहले एक बड़े एक, और reactive autoscaling को safety net के रूप में रखें। Generic version यह argument Autoscaling for Traffic Spike में है।

Rollout probe

Tested, फिर fixed: हमारा पहला backend template rollout एक short 503 blip produce किया, क्योंकि DigitalOcean पुराने droplet delete किया जबकि load balancer अब भी उन्हें routing किया। Guarded rollout सिर्फ़ image change करता है, हर नए node के /lb-health answer देने तक wait करता है, लगभग 40 second wait करता है balancer को उन्हें admit करने के लिए, और पुराने node drain करता पहले। 7 अक्टूबर दोनों pool का full rollout real page हर 2 second एक uptime probe के अंतर्गत run किया: 219 probe, 0 error।

जहाँ scaling helped, और जहाँ help नहीं किया

यह table है मैं wish किया मैंने शुरू करने से पहले देखा। हर problem test expose किया या production के लिए, एक सवाल पूछता है: ज़्यादा server इसे fix किया होता?

Problem found	ज़्यादा server?	क्या इसे fix किया	Status
Backend CPU saturated 65 to 70 request/s per node	हाँ	Autoscale pool (2 to 10 node) plus pre-scaling	Implemented
पूरा school 429 (25 सितंबर)	नहीं	Limiter per विद्यार्थी account, IP सिर्फ़ guest	Implemented
Route throttle अब भी IP से count: एक dashboard endpoint के 74% call exam में 429 return (7 अक्टूबर)	नहीं	Throttle per विद्यार्थी per route counted; 0 ऐसे 429 बाद	Implemented
2,854 Valkey connection timeout (6 अक्टूबर)	नहीं	Valkey in place 8 GB x 2	Implemented
Merit card (0.34-second job) 10 to 115 मिनट wait AI job 10 second पर (6 अक्टूबर)	नहीं	AI job के लिए अलग queue lane; merit card लगभग 1 मिनट ready	Implemented
Backend हर विद्यार्थी के लिए एक frontend IP देखता है	नहीं	Real विद्यार्थी IP एक signed header में pass करो	Planned

छह problem में से, एक capacity problem था। अन्य पाँच दो rule, एक connection limit, एक queue layout और एक missing header थे। Data-tier side यह pattern The Data Tier Under Load में cover है।

Soak testing: हमने क्या run किया और क्या नहीं

एक load test पूछता है कितना system ले सकता है। Soak test पूछता है कितना लंबे यह ले सकता है: एक engine full rev पर एक मिनट तीन घंटे के बारे में लिखता little prove करता है, क्योंकि slow problem देर show up करते हैं (memory जो creep up, connection जो leak, disk जो fill, queue जो drift)। "हमने इसे soak test किया" कहना आसान है और defend करना hard है, तो मैं exact हूँ: हमने अभी तक एक formal soak test नहीं run किया।

Evidence	क्या यह cover करता है	Status
Short sustained run: 25 से 500 requests/s climb, 16-minute autoscale test लगभग 750 requests/s तक, एक real page हर 2 second rollout के through uptime probe	मिनट sustained load: 0 application error climb में, 0 server error autoscale test में	Tested
7 अक्टूबर exam evening: लगभग दो घंटे, दो exam back to back	Steady CPU, 0 failed job, एक scale-in mistake	Observed production में
एक multi-hour soak एक agreed maintenance window में अगले बड़े load test के साथ	Memory growth, connection leak, queue drift	Planned

Exam evening closest चीज़ है हमारे पास, लेकिन यह एक observation है, controlled test नहीं। एक related check does hold: backend node 24 घंटे में 0 file local disk में write, तो disk soak risk नहीं हैं वहाँ। Frontend node अभी भी लगभग 440 MB nginx log एक दिन locally रखते हैं, यही वजह Fluent Bit frontend पर Planned list में है।

Real exam: 7 अक्टूबर production proof के रूप में

कुछ real विद्यार्थी replace नहीं करता। दो exam run back to back, और हमारा once-a-minute digest उन्हें watch किया: विद्यार्थी started और submitted, request और 5xx per node, pool CPU, worker load और failed job।

Measure	Result
Exam A (20 मिनट)	661 started, 638 submitted (96.5%); start peak 86 एक मिनट में
Exam B (25 मिनट)	439 started, 425 submitted (96.8%)
Frontend	Exam A में लगभग 1,741 unique visitor, peak 403 एक मिनट में; 6 to 8 pm से लगभग 732,000 request; CPU up to 24%
Backend	Peak लगभग 69 requests/s (per-minute log; 63 provider दो-minute average पर); CPU up to 47% दो-minute average पर; एक node 86% एक मिनट के लिए
MySQL	CPU max 24.5% (average 13.4%), सबसे ज़्यादा 5 running query, 0 lock wait
Valkey	12.5% memory
Worker	CPU 46%, 0 failed job

तीन चीज़ें stand out.

1. Bottleneck backend CPU per node है, और database के पास लगभग 6 times headroom है। नीचे model MySQL limit near 450 requests/s रखता है, against 69 शाम पर।
2. Test number evening predict किया। 63 request per second 59 ms CPU per पर लगभग 3.7 CPU-second per second है। 2 4 vCPU node के पास 8 vCPU, तो average लगभग 46% should होना चाहिए। Dashboard 47% show किया।
3. Average node जो hurt को hide करता है। Traffic दो backend node के बीच 65/35 split किया, क्योंकि long-lived keep-alive connection frontend proxy से traffic pin करते हैं। Dashboard 47% कहते जबकि एक node minute के लिए 86% को touch किया।

Scale-in की गलती

एक exam के बीच में, किसी ने backend pool minimum को lower किया। DigitalOcean एक serving node remove किया बिना drain, और लगभग 360 request 2 मिनट में failed। पहले test सिखाते थे scale-out slow और late है। Exam दूसरा सिखाता: scale-in quick है और goodbye नहीं कहता। Implemented runbook rule के रूप में: exam से पहले minimum raise करो, सिर्फ़ बाद lower करो, और कभी autoscale scale-in को drain एक node trust नहीं करो।

Capacity model: क्या यह कहता है, और जहाँ यह stop करता है

Exam के बाद मैंने real data को एक छोटे model में बदला, तो अगले exam को arithmetic के साथ plan किया जा सकता fear के बजाय। इसके पास चार measured input हैं: लगभग 15 request एक विद्यार्थी जब exam open करता, फिर लगभग 1.5 एक मिनट (0.025 एक second); लगभग 30 requests/s baseline traffic; 50 requests/s एक backend node के लिए safe load (75% CPU); और 30% margin uneven splitting के लिए।

सादी शब्दों में: node लो जो आप होंगे, 50 से multiply करो, uneven margin के लिए 1.3 से divide करो, और 30 baseline traffic को subtract करो। जो रहता है वह क्या विद्यार्थी moment को last join को use कर सकते। हर विद्यार्थी उनके 15 opening request cost करता spread join window भर, plus 0.025 present होने के लिए।

4 node लो। 4 x 50 / 1.3 लगभग 154, और minus 30 लगभग 124 छोड़ता है। अगर विद्यार्थी 10 मिनट भर join, हर एक 15 / 600 + 0.025 = 0.05 request/s cost, तो 124 / 0.05 लगभग 2,500 विद्यार्थी; table 2,400 में round down। अगर सब 2 मिनट में join, हर एक 15 / 120 + 0.025 = 0.15, जो लगभग 800 देता है।

Backend node	~10 मिनट भर joining	सब ~2 मिनट में joining	Safe backend load (derived)
2	लगभग 900	लगभग 300	लगभग 77 request/s
4	लगभग 2,400	लगभग 800	लगभग 154 request/s
6	लगभग 4,000	लगभग 1,300	लगभग 231 request/s
8 to 10	5,500 या ज़्यादा	1,800 to 2,300	लगभग 308 to 385 request/s

Real evening पहली row fit: 86 start per मिनट की peak के विरुद्ध लगभग 90 एक मिनट वह row allow। जहाँ model stop:

• यह एक multiple-choice exam से आता है। Written exam PDF upload के साथ worker बहुत ज़्यादा load करते हैं और must separately measured।
• Row 3 node के ऊपर extrapolated; most हमने test में देखा 3 node, briefly 4। Planned: एक maintenance window में full load test।
• Node सिर्फ़ एक बार count करते exist। एक metric जो 5 to 8 मिनट lag करता और पहला extra node लगभग CPU hit करने के 7 मिनट बाद, table एक pre-scaling guide है, reactive scaling का promise नहीं।
• यह सिर्फ़ backend request path को cover करता है। Worker, Valkey और AI provider का rate limit के पास अपना ceiling है।

Final architecture, layer by layer

Solid box आज run करते हैं; dashed strip planned है।

1. Edge। दो load balancer, एक per tier। Rejected: दोनों के लिए एक, क्योंकि DigitalOcean balancer host या path से route नहीं कर सकता।
2. Frontend pool। 2 to 10 node, nginx front में दो Next.js container (एक per vCPU), 70% CPU पर scaling।
3. Backend pool। 2 to 10 node एक golden snapshot से, सिर्फ़ nginx और php-fpm, CPU target 55% (यह 70% शुरू)। Web node पर कोई job नहीं, तो extra node कभी एक दो बार नहीं चलाते।
4. Data। MySQL Standard 8.4 (4 vCPU / 16 GB, primary और standby, standby पर read, sticky = true); Valkey 8 GB दो node पर; PostgreSQL pgvector (2 vCPU / 4 GB) kept अलग, तो vector query कभी exam write के साथ compete नहीं।
5. Worker। एक fixed 4 vCPU / 8 GB droplet queue lane के लिए (AI lane सहित), scheduler, WebSocket और सब SMS, क्योंकि SMS gateway एक IP को whitelist।एक known single point of failure।
6. File, log, watching। Spaces CDN पीछे; backend log Fluent Bit के through OpenSearch में; हमारा ops console हर tier sample read-only और guarded deploy run।

पहले और अब

Area	पहले (5 अक्टूबर तक)	अब
Frontend	एक 8 vCPU / 16 GB droplet, एक Next.js container, कोई load balancer नहीं	Load-balanced pool 2 to 10 node, दो container per node
Backend	दो fixed droplet, ID से targeted, तो नए server कभी join नहीं कर सकते	Balancer tag को target करता है; 2 to 10 एक snapshot से pool, pre-scaled exam से पहले
MySQL	एक Advanced node, 8 vCPU / 32 GB, कोई standby नहीं	Standard 4 vCPU / 16 GB, primary और standby
"Standby" server	दो powered-off droplet, $112 एक महीने में, power-on के लिए मिनट	Remove; real standby MySQL और Valkey में (अब 8 GB, 4 से ऊपर)

Money क्या खरीदता है

Item (monthly, DigitalOcean list price)	Cost
पहले: पूरी web tier (16 GB frontend, 2 backend, worker, 1 load balancer, 2 powered-off standby)	लगभग $416
अब, web tier: 2 backend ($56 each), 2 frontend ($28 each), worker, दो load balancer	$112 + $56 + $56 + $48
अब, data और log: MySQL pair, Valkey 8 GB x 2, PostgreSQL, OpenSearch	लगभग $389 + $240 + $60 + $20
अब: snapshot, Spaces	लगभग $5 + $5 और usage
अब: total production, backend pool 2 node पर	लगभग $990

Total like के लिए नहीं है: $416 web tier सिर्फ़ थी, और $990 पूरा production stack है। Same list price पर web tier अब लगभग $272 है। अन्य $709 managed MySQL, Valkey, PostgreSQL और OpenSearch है, और यही extra money खरीदता है: एक database जो node failure से survive करता है, room के साथ Valkey और एक standby, vector search जो exam write से अलग रहता है, और log जो deleted node को outlive करते। Pre-scaling सस्ता part: एक extra backend node लगभग $0.08 एक घंटे cost करता है। Decision के पीछे number नीचे checklist में हैं।

Planned, और done नहीं

• Planned: एक full load test और एक maintenance window में formal multi-hour soak, अगले बड़े exam से पहले।
• Planned: Next.js static asset CDN से, Frontend node पर Fluent Bit, और एक signed real-IP header frontend से backend तो हर per-IP rule और log exact है।
• Planned: Worker high availability: एक reserved IP SMS gateway के साथ whitelisted, एक छोटा standby worker, और एक exam-only burst worker बड़े exam से पहले शुरू।
• Considered: Kubernetes (DOKS) seconds-level scaling के लिए, जो चलाने के लिए बहुत अधिक। एक warm standby 3 to 4 second में ready में भी considered, लेकिन DigitalOcean pool के पास कोई warm pool नहीं, तो हमने pre-scale करते और balancer के अंदर spare capacity रखते।

Solutions Architect का checklist

यह checklist है मैं अब architecture review में use करता हूँ। हर item कुछ यह project किया या pay किया।

Scalability

• Web node stateless: session, cache और queue Valkey में, upload Spaces में, 24 घंटे में 0 file disk में लिखे।
• हर tier अपने unit से scale करता है: दो Next.js container per frontend node, php-fpm worker per backend node।
• Known load pre-scaled; reactive scaling सिर्फ़ safety net है।

Availability

• कोई भी single node site को down ले सकता: दो balancer, pool minimum 2, MySQL और Valkey के लिए standby।
• Health check nginx अकेले answer दिया, और node drain (503 पर /lb-health) remove होने से पहले।
• पुरानी system तब तक रहता है जब तक traffic सच में left: DNS switch घंटा बाद अब भी 36% मिला।

Performance

• CPU per request जानो (59 ms), सिर्फ़ नहीं request per second।
• Per-request setup cost को watch: fresh TLS connection लगभग 5.4 ms CPU Valkey और 3.3 ms MySQL के लिए cost करता।
• Read standby और primary के बीच बँटते हैं, write primary पर जाते हैं, और विद्यार्थी फिर भी अपना answer तुरंत देखता है।

Reliability

• Slow job अपना queue lane पाते, तो 0.34-second job कभी 10-second के पीछे wait नहीं।
• बाहरी provider के लिए call paced और retry (8 एक मिनट shared, backoff 1 to 15 मिनट, 12 घंटे), तो विद्यार्थी कभी error नहीं देखते।
• Rate limit per विद्यार्थी count, per IP नहीं, जहाँ बहुत विद्यार्थी एक address share करते।

Observability

• एक once-a-minute digest exam के दौरान: started और submitted, request और 5xx per node, pool CPU, worker load, failed job।
• हर node को देखो, सिर्फ़ pool average नहीं (47% के विरुद्ध 86%)।
• Log node outlive: Fluent Bit backend के लिए OpenSearch में; frontend Planned।

Failure recovery

• Managed database backup और failover, golden snapshot, और rollback के लिए last 3 अच्छे image।
• हर cutover एक तरीका back रखता है: पुराना database 48 घंटे frozen, पुराना frontend जब तक DNS drain।
• Single point of failure को लिख दो। Worker एक: अगर यह मर, SMS, scheduler और exam processing stop जबकि submission safely Valkey में wait करते।

Cost

• Size choose करने से पहले headroom measure: frontend test के बाद shared CPU में moved, और Standard MySQL replica (सस्ता और highly available) एक बड़े Advanced node replace।
• Spend remove जो कुछ नहीं खरीदता: दो powered-off standby $112 एक महीने cost किए availability नहीं के साथ।
• Pre-scale instead over-provisioning, और spend जहाँ यह real failure remove, बड़े Valkey की तरह।

Maintainability

• कभी hand-edit pool node: एक change, test, snapshot, pool template को snapshot पर point करो।
• हर setting pool update में pass, तो कुछ silently reset नहीं।
• नई guard fix के बिना fail test के साथ ship, per-student throttle की तरह।

Future growth

• Connection math को लिख दो: 10 node x 80 php-fpm worker 800, MySQL 1,601 के अंतर्गत।
• अगली ceiling जानो: MySQL near 450 requests/s, night peak के 6 times के लगभग।
• Written exam को separate पर measure, और account limit check जल्दी: droplet limit 25 दोनों pool अपने maximum तक rollout में reach से पहले raise करना पड़ा।

हमने क्या सीखा, और यह हमें जहाँ छोड़ता है

1. पहला bottleneck rarely वह है जो तुमने feared। हमें server के बारे में worry था; पहली तीन problem एक rate-limit rule, एक connection limit और एक queue layout थे।
2. Symptom नहीं, cause fix करो। एक problem में छह सिर्फ़ capacity problem था।
3. Production को model के विरुद्ध check करो। 63 request/s 59 ms लगभग 46% CPU predict, और हमने 47% देखा।
4. Average node जो hurt को hide, और scale-in abrupt है। 47% average पर, 86% एक node पर; exam से पहले minimum raise करो और सिर्फ़ बाद।
5. कहो क्या तुमने test नहीं किया। हमारे पास load test और एक real evening; एक formal soak Planned।

जब यह series शुरू हुआ, platform एक frontend droplet, दो backend droplet ID से pinned और एक बड़ा database node था। 7 अक्टूबर की exam evening एक अलग system पर run किया, और difference सब कुछ नहीं आया server add करने से sake के लिए। यह same loop, फिर से, including times measurement ने कहा हमें हमारे गलत।

Measure। Bottleneck ढूँढो। इसे समझो। एक चीज़ change करो। Test। फिर से measure करो।

यह loop architecture है; pool, standby और diagram जो छोड़ता है। अगर तुमने इन पाँच part से एक चीज़ रखो, loop रखो, और अगले exam night, sale या launch से पहले इसे use करो।

सब पाँच part के लिए पढ़ने के लिए धन्यवाद। वापस जाने के लिए, part 1, starting point और high availability से शुरू करो, फिर part 2, scaling application layer, part 3, database और part 4, Valkey, worker और logging। यह series का अंतिम part था।