काल्पनिक नाम, लेकिन real संख्या: एक frontend server, दो fixed backend, एक database node और दो powered-off standby। इस भाग में high availability की definition है और bottleneck बार-बार हटता है।
Author
Anichur Rahaman
Part 1 of 5
एक सर्वर से परीक्षा-दिन तक तैयार25 सितंबर को परीक्षा के दौरान विद्यार्थियों को HTTP 429 "बहुत ज़्यादा अनुरोध" दिखने लगे। समस्या सर्वरों की कमी नहीं थी। यह एक नियम था जो ग़लत चीज़ गुन रहा था: एक rate limiter IP address से गिन रहा था, और एक स्कूल सैकड़ों विद्यार्थियों को एक address के पीछे रखता है। limiter को एक पूरी इमारत एक बहुत ही बेसब्र आदमी दिख रहा था।
ग्यारह दिन बाद, 6 अक्टूबर को 02:28 पर, एक backend load test 2,854 application error दे गया। हर एक यही कह रहा था: Valkey से connection timeout हो गया। एक अलग layer, एक अलग कारण, एक अलग हल। उसके बाद सिर्फ़ CPU रहा, जो वह समस्या है जिसे ज़्यादा सर्वर से सच में हल होता है।
यह क्रम इसी project की असली कहानी है: bottleneck बार-बार हटता रहा। सर्वर जोड़ना architecture नहीं है। यह कई काम में से एक है, और आख़िरी।
सितंबर के अंत से 7 अक्टूबर 2026 तक, हमने DigitalOcean पर एक Laravel और Next.js प्लेटफ़ॉर्म को एक frontend सर्वर और दो fixed backend से एक scheduled exam peak के लिए तैयार setup में ले गए। यह पहला हिस्सा starting point को cover करता है: business की समस्या, जो हमें मिला उसे, क्यों यह काफ़ी नहीं था, "high availability" हमारे लिए क्या मतलब था, और पहले test ने हमें क्या सिखाया।
शुरुआत से पहले: NovaCommerce एक काल्पनिक नाम है, इस case study के लिए। मैंने कुछ भी ऐसा नहीं रखा जो कंपनी, उसके सर्वर या विद्यार्थियों को पहचान सके।
यह "From One Server to Exam-Day Ready" five-part case study का हिस्सा 1 है। NovaCommerce एक काल्पनिक नाम है; architecture, संख्याएँ और गलतियाँ वास्तविक हैं।
NovaCommerce एक online platform है जो courses बेचता है और विद्यार्थियों के लिए timed online exams चलाता है। लोग sign up करते हैं, pay करते हैं, live exams लेते हैं, अपने results देखते हैं और AI study help इस्तेमाल करते हैं।
ज़्यादातर web traffic एक पहाड़ी है: सुबह बढ़ता है और रात को गिरता है। Exam traffic एक cliff है। concert hall के दरवाज़ों की तरह सोचें। घंटों कुछ नहीं होता, फिर दरवाज़े खुलते हैं और सब एक साथ आते हैं। जब एक scheduled exam शुरू होता है, हज़ारों विद्यार्थी एक ही मिनट में platform पर आते हैं।
अच्छी बात है कि cliff का एक timetable है। हम जानते हैं कि यह कब आएगा। मैं इस फ़ायदे को general terms में traffic spikes के लिए autoscaling के guide में बताता हूँ। यह series दूसरा आधा है: एक असली platform, असली संख्याओं के साथ।
Business ने हमें चार requirements दी, सादी भाषा में।
इस series में हर technical choice इन चार lines में से किसी एक पर जाता है।
यहाँ setup है जैसा हमने 5 अक्टूबर 2026 से पहले पाया, एक DigitalOcean region में और एक private network में।
Frontend एक single droplet था जिसमें 8 vCPU और 16 GB memory था, एक Next.js container चला रहा था। Domain सीधा इस पर point करता था, और TLS certbot से droplet पर आता था। कोई load balancer नहीं था। अगर यह सर्वर मर जाता, तो site down हो जाता।
यह पैसे भी बर्बाद कर रहा था। एक Node.js process roughly एक core पर render करता है, तो ज़्यादातर आठ vCPU idle बैठे थे: एक दुकान आठ tills के साथ और एक cashier।
एक DigitalOcean load balancer दो fixed backend droplet के सामने था, हर एक 4 vCPU और 8 GB के साथ। Application Laravel है (PHP-FPM) nginx के पीछे Docker में, दो container per node: nginx के लिए web और php-fpm के लिए app। Queues (Horizon), scheduler और Reverb, WebSocket server live updates के लिए, एक worker पर चलते थे।
Load balancer हर backend को अपने fixed ID से target करता था, tag से नहीं। यह एक guest list जिसमें नाम लिखे हों और एक rule जो "कोई भी staff badge पहने" के बीच का फ़र्क़ है। नामों के साथ, एक नया सर्वर कभी अपने आप अंदर नहीं जा सकता। किसी को list edit करनी पड़ती है।
यहाँ अच्छी बात थी, और यह बाकी सब से ज़्यादा मायने रखती थी। Backend web nodes पहले से ही stateless थे। Sessions, cache और queues managed Valkey में रहते थे, और logs stderr को जाते थे। एक सर्वर जिसे बिना कुछ खोए delete किया जा सके एक सर्वर है जिसे multiply किया जा सकता है। इस property के बिना series का बाकी हिस्सा हो नहीं सकता था।
Database एक Managed MySQL "Advanced" node था 8 vCPU और 32 GB के साथ: एक single node, कोई standby नहीं।
फिर दो "standby" droplet थे, एक backup के रूप में रखे गए। वे powered off थे। एक powered-off droplet अब भी पैसे लेता है, और एक को ऊपर लाने में मिनट लगते हैं। यह एक spare टायर एक locked garage के पार शहर में है: यह exist करता है, आप इसके लिए pay करते हैं, और जबकि आप सड़क पर stuck हैं यह मदद नहीं करता। यह high availability नहीं है।
दो छोटी चीज़ें कोने में बैठी थीं। Load balancer के TLS certificates manual uploads थे जिनके expiry date थे, तो renewal एक recurring task था जिसे किसी को याद रखना था। और account की droplet limit 25 थी, जो मायने रखती थी एक बार दो pools grow कर सकते और nodes replace कर सकते (part 2)।
| Setup का हिस्सा | कैसे बनाया गया था | Stress या failure के अंतर्गत क्या होता है |
|---|---|---|
| Frontend | एक 8 vCPU / 16 GB droplet, एक Next.js container, कोई load balancer नहीं | अगर यह मरता है तो site down; ज़्यादातर cores idle, क्योंकि एक Node process लगभग एक core इस्तेमाल करता है |
| Backend | दो fixed 4 vCPU / 8 GB droplet एक load balancer के पीछे, ID से target किए गए | कोई automatic growth नहीं; एक नया सर्वर कभी अपने आप join नहीं कर सकता |
| Database | एक Managed MySQL node, 8 vCPU / 32 GB, कोई standby नहीं | अगर node fail करता है तो कोई दूसरा node लेने के लिए तैयार नहीं |
| Standbys | दो droplet, powered off | Off होने पर भी bill किए जा रहे हैं; ऊपर लाने में मिनट लगते हैं |
देखें कि उस table में क्या missing है: एक bug। कुछ नहीं टूटा था। Setup वह करता था जिसके लिए यह बनाया गया था। Trouble एक scheduled cliff और एक setup के बीच mismatch था जो एक सर्वर नहीं खो सकता, अपने आप एक नहीं जोड़ सकता, और अपनी spare capacity को switched off रखता है। आप एक mismatch को patch नहीं कर सकते। आपको system की form change करनी पड़ती है, और यही architecture मतलब है।
"High availability" एक ऐसा phrase है जिसमें सब लोग सिर हिलाते हैं और कोई define नहीं करता। हम कुछ भी change करने से पहले, हमने लिख दिया कि यह इस platform के लिए क्या मतलब है। यह चार lines में आ गया।
कोई भी single server जिसका loss site को down ले जाए। Database एक node के loss से survive करता है। Deploys और scale-in विद्यार्थियों को invisible होते हैं। Capacity एक exam के बाद नहीं, पहले ready है।
मुझे एक definition पसंद है जिसे आप एक सवाल से test कर सकते। क्या हम किसी भी एक सर्वर की plug निकाल सकते और serving चलती रहती है? क्या एक database node fail कर सकता है बिना exam रुके? क्या हम एक release ship कर सकते बिना विद्यार्थी को notice किए? क्या capacity पहले से ही वहाँ है जब पहला विद्यार्थी "start" click करता है?
दो business rules इसके ऊपर बैठते हैं: submissions कभी नहीं खोते, और cost sane रहता है। Figure हर requirement को map करता है इस layer को जो इसे deliver करता है और series के इस part को जो इसे cover करता है।
Definition की आख़िरी line, "पाँच मिनट बाद नहीं", वह दर्द पहुँचाने वाली है। हमारे tests में, autoscaling पहला extra node लगभग सात मिनट बाद add करता था CPU 99% तक पहुँचने के बाद। सात मिनट लंबा समय है जब एक exam एक मिनट में शुरू होता है। Capacity cliff से पहले वहाँ होना चाहिए, बाद में नहीं।
Definition लिखने के बाद, हमने वह किया जो method चाहता है: पहले measure करो। सितंबर के अंत से 6 अक्टूबर तक हमने production को देखा और load test चलाए, और एक क्रम में तीन समस्याएँ पाईं। वे unrelated दिखते हैं, और यही बात है।
Production पर measured: विद्यार्थियों को exams के दौरान HTTP 429 मिल रहे थे। Global API rate limiter IP से keyed था, क्योंकि default auth guard token-based विद्यार्थियों के लिए empty था, तो limiter नहीं बता सकता था कि एक विद्यार्थी कौन है। एक school या एक mobile carrier सैकड़ों विद्यार्थियों को एक NAT address के पीछे रखता है, और पूरी इमारत एक bucket share करती है।
Status: Implemented। हमने API limiter को per student या instructor account से keyed किया, और IP से सिर्फ़ guests के लिए। ज़्यादा सर्वर मदद नहीं देते; rule "no" कह रहा था, hardware नहीं। यह bug का एक क़रीबी cousin 7 अक्टूबर को route-level throttle में फिर से आया, और यह कहानी part 4 में है।
6 अक्टूबर को 02:28 पर, एक backend load test 2,854 application 500 error दे गया। हर एक RedisException: Operation timed out था जबकि connecting, 5 second connect timeout के साथ। Valkey (4 GB, primary plus standby) load के अंतर्गत connections को fast enough accept नहीं कर सकता था।
कैसे app ने इसे इस्तेमाल किया ने pressure add किया। हर request ने Valkey को (लगभग 5.4 ms CPU per request) और MySQL को (लगभग 3.3 ms) एक fresh TLS connection खोला। एक दुकान की कल्पना करें जहाँ हर customer को हर बार buzz किया और door पर check किया जाता है। एक भीड़ के अंतर्गत, door queue बन जाता है।
Status: Implemented, फिर Tested। हमने Valkey को in place resize किया 8 GB को दो nodes के साथ (primary और standby), data रखा गया और host unchanged। फिर हमने एक gradual ramp के साथ retest किया 25 से 500 requests per second तक, 2 backend nodes पर शुरू करते हुए जबकि pool scale out: 0 application error और 0 backend 5xx। Load balancer पर 143 error थे, लेकिन सिर्फ़ जबकि nodes CPU-saturated थे। यह expected "out of capacity" signal है, bug नहीं। Data tier को part 3 मिलता है, और Valkey part 4 में return करता है। General theory के लिए, data tier under load देखें।
पहले दो fixed होने के बाद, जो रहा वह सिर्फ़ arithmetic था। एक 4 vCPU / 8 GB backend node लगभग 65 to 70 requests per second के असली API mix को serve करता है full CPU पर, लगभग 59 ms CPU per request। हर बाद का capacity decision इस नंबर पर बनाया गया है।
यह तीन bottleneck में से सिर्फ़ वह है जो ज़्यादा सर्वर सच में solve करते हैं, और यहाँ भी timing trap है: पहला extra node लगभग सात मिनट बाद आया CPU 99% को hit करने के बाद। कैसे हमने capacity जल्दी लाया यह part 2 का विषय है।
तो order था एक limiter (code), फिर Valkey connections (data-tier sizing), फिर backend CPU (capacity)। अगर हमने सर्वर add करके शुरू किया होता, limiter अब भी 429 कहता और Valkey अब भी timeout करता।
नए shape के बारे में बात करने से पहले, यह जानना मदद करता है कि पुराना क्या cost करता था। ये पुराने web tier के लिए monthly DigitalOcean list prices हैं।
| चीज़ | Cost | यह क्या खरीदता था |
|---|---|---|
| पुराना web tier: frontend, दो backend, worker, एक load balancer, दो standbys | लगभग $416 एक महीने में | एक running site कई single point of failure के साथ |
| दो powered-off standby droplet | $112 एक महीने में | कोई availability नहीं: off होने पर भी bill, ऊपर लाने में मिनट |
| एक extra backend node, comparison के लिए | लगभग $0.08 एक घंटे में | Capacity जो सच में requests serve करता है |
$112, web tier का थोड़ा ऊपर एक चौथाई, वह नंबर है जो मेरे साथ रहा। यह दो सर्वर खरीदता था जो एक भी request serve नहीं कर सकते। एक extra backend node को pre-scale करना लगभग $0.08 एक घंटे में cost करता है, तो एक शाम के लिए capacity बढ़ाना cents cost करता है। महीना भर में ऐसी capacity के लिए pay करना जो switched off है safe महसूस करने का ज़्यादा महंगा तरीका है।
एक honest note: $416 सिर्फ़ web tier को cover करता है, database, Valkey या storage को नहीं, तो यह एक full bill के साथ compare नहीं हो सकता। Part 5 में मैं like को like के साथ compare करता हूँ।
Pattern जो हमने पूरे project में दोहराया वह जो आपने अभी देखा: measure, bottleneck ढूँढो, कारण समझो, architecture बदलो, फिर से test करो, और फिर से measure करो। ज़्यादा सर्वर जोड़ना architecture नहीं है। Architecture यह चुनना है कि कौन सी layer बदले, और क्यों।
यहाँ five part कैसे fit होते हैं।
| Part | Layer | आप क्या देखेंगे |
|---|---|---|
| 1 (यह part) | Starting point | Business की समस्या, पुराना setup, high availability की definition, पहले bottleneck और पुरानी cost |
| 2 | Application layer | दो load balancer, दो autoscale pool, pre-scaling, image-based deploy और rollout lesson |
| 3 | Database | एक MySQL node से एक 26-minute window में एक primary with standby तक, read/write split, PostgreSQL with pgvector |
| 4 | Valkey, worker, log | Queue, worker, logging, monitoring और एक real exam के दौरान scale-in की गलती |
| 5 | Proof | 7 अक्टूबर की real exam evening, load और soak testing, और final architecture |
हमने भी ideas consider किए जो हमने build नहीं किए, और मैं हर एक को label करता हूँ। दोनों tier के लिए एक load balancer Considered था, फिर Rejected। एक "warm standby ready in seconds" Considered था, लेकिन autoscale pool के पास कोई warm pool नहीं है, तो हमने पहले से ही serving करने वाली spare capacity plus pre-scaling इस्तेमाल किए। Kubernetes बाद में Considered है और implemented नहीं है।
सब कुछ finished नहीं है, और मैं कहता हूँ। Single worker server एक known single point of failure है; इसे fix करना Planned है, नहीं done (part 4)। एक formal multi-hour soak test भी Planned है (part 5)।
Checklist के रूप में goal, हर line के साथ जो part जो इसे build या test करता है।
अगले, part 2 में, हम application layer build करते हैं: दो load balancer, दो autoscale pool, pre-scaling, और एक rollout method जो एक short 503 blip से सीखा गया।
About the Author
Anichur Rahaman
Continue Reading
