App instance जोड़ना और एक और checkout सफल करना अलग हैं। Readiness time मापें, सीमित tier जाँचें और failure के लिए capacity बचाएँ।
लेखक
Anichur Rahaman
रात बारह बजे scheduled promotion शुरू होता है। Origin demand 20 से 440 requests/second पहुँचती है और टीम scaling rule का इंतज़ार करती है। Machine चलने के बाद भी image pull, application boot, registration और cache warmup बाकी हो सकते हैं। “Running” और उपयोगी checkout के बीच दूरी है। यह उदाहरण है, reported incident या StoreConsole benchmark नहीं।
जानी demand तैयारी का समय देती है; अधिक machines मदद करेंगी ही, यह तय नहीं। Plan को arrival pattern, वास्तविक paths, shared constraints और ready होने का समय जोड़ना चाहिए। Engineering for High Volume का यह part 1 edge से application तक का रास्ता है।
Reactive scaling एक control loop है: signal देखना, evaluate करना, capacity माँगना, workload शुरू करना और traffic देना। Warm pools या तेज processes जल्दी आ सकते हैं; धीमी image, quota और cold dependencies देर कर सकते हैं। Universal एक-से-तीन मिनट minimum या हर policy का एक cooldown नहीं।
AWS step/simple scaling और warmup अलग बताता है। Actual policy, metric period, evaluation और scale-in पढ़ें। Simple scaling का default हर target-tracking scale-out से पहले की देरी नहीं। अपने environment में failed provisioning और readiness समेत critical path मापें।
सिर्फ़ planning example में serial detection/control 60 seconds, provisioning 90, registration/health 30 और warmup 30 मानें: total 210 seconds, यानी 3 minutes 30 seconds । वास्तव में stages overlap कर सकते हैं। Observed slow case और उचित buffer से पहले capacity schedule करें; running VMs की संख्या readiness नहीं।
| उदाहरण serial stage | Seconds | Cumulative seconds |
|---|---|---|
| Detection/control | 60 | 60 |
| Provisioning | 90 | 150 |
| Registration/health | 30 | 180 |
| Warmup | 30 | 210 |
जाने event के लिए scheduled/predictive तैयारी, बाकी variation के लिए reactive rules और maximum spend/capacity तय करें। Pre-scaling की लागत है और वह fail भी हो सकती है। Quotas, availability और dependencies जाँचें; tested capacity से अधिक demand पर admission control या सच्चा waiting experience रखें।
Cached static assets, public-page hits, dynamic renders, API calls, checkout writes और background jobs अलग करें। Edge requests, origin requests, users और orders एक unit नहीं। Next.js page API बुला सकता है; monolith internal SSR से render कर सकता है; कुछ APIs SSR छोड़ते हैं। हर request को काल्पनिक एक chain में न डालें।
Explicit host/locale/variant policy से immutable assets और वास्तव में shareable responses cache करें। Personal accounts, carts, permission-dependent content और sessions सेट करने वाले responses को उचित bypass/private handling चाहिए। Public दिखता page भी personalised हो सकता है। Warm/cold cache, invalidation, stampede और actual hit ratio जाँचें।
WAF/rate controls और load balancer में भी connections, TLS, bandwidth, registration, quotas और health limits हैं। Managed अपने आप unlimited या कभी bottleneck न होने का प्रमाण नहीं। AWS ALB capacity reservation sudden events के लिए provider-specific option है; पुराने doubling claims के बजाय वास्तविक workload से estimate/verify करें।
Health check केवल वही साबित करता है जो जाँचता है। Dependency-aware probes और journeys से readiness जाँचें, लेकिन एक shared service खराब होने पर सभी उपयोगी nodes हटाने वाला design न रखें। Draining, propagation और grace periods test करें। Drain disruption घटाता है, invisible scaling या failed request ठीक करने की गारंटी नहीं।
Instance गायब होने पर sessions, uploads, job ownership, locks और mutable business state उपलब्ध रहें। Suitable shared database/session store या durable shared/object storage मदद कर सकते हैं। Redis/S 3 विकल्प हैं, हर deployment की अनिवार्यता नहीं। Local immutable cache वैध हो सकती है। Shared coordination/invalidation और expendable local cache की consistency ज़रूरत अलग है।
Next.js self-hosting guidance multi-instance caches और build/version मुद्दे समझाती है। Compatible artifacts के साथ invalidation, identity/secrets और generated assets coordinate करें। Shared cache store अकेला हर cache type, tag और in-flight version की safety नहीं साबित करता।
Scheduled work coordinate करें और duplicate effects रोकें। Laravel scheduler documentation shared atomic-lock single-server scheduling बताती है। Lock, expiry/failover और unique operation identity के failure tests फिर भी चाहिए; केवल एक node का cron complete exactly-once design नहीं।
वास्तविक proxy/app path के body/time limits और upload behaviour मिलाएँ, हर काल्पनिक service के नहीं। Node failure से accepted upload या payment result न खोएँ। Authoritative service tenant/record permission फिर जाँचे; scale-out नया अधिकार नहीं देता।
Node event loop का CPU-bound JavaScript saturate हो सकता है जबकि अन्य cores idle हों। इसका अर्थ process अन्य cores कभी इस्तेमाल नहीं कर सकता, नहीं: native work, runtime background और worker threads तस्वीर बदलते हैं। More processes, render/cache बदलाव या code optimisation से पहले per-process CPU, event-loop delay, memory/GC, I/O और backend waits मापें।
PHP-FPM के official pool settings concurrency और lifecycle नियंत्रित करते हैं। अलग steady-state उदाहरण में 200 requests/second worker execution शुरू करते हैं और mean worker-occupied time 0.15 seconds है: औसतन 30 occupied workers । यह 60 children, cores या database connections तय नहीं करता; mean की जगह p95 नहीं रख सकते।
Illustrative incremental/private-memory budget 100 MiB per worker पर 60 workers को 6,000 MiB≈5.86 GiB चाहिए, OS, दूसरे services और shared-memory allowances से पहले। Shared OPcache को हर बार private memory न जोड़ें। Real peaks और downstream connection/CPU limits मापें। FPM concurrency बढ़ाने से उपयोगी throughput के बजाय database overload हो सकता है।
उचित process mode/cache को safe representative requests से warm करें। Timestamp checks बंद करने वाले OPcache settings में serving processes refresh करने की release procedure चाहिए; copied setting या CLI reset सार्वभौमिक safety नहीं। Processes/containers की startup/warmup भी लंबी हो सकती है, इसलिए seconds-level scaling मापें।
सिर्फ़ इस planning table में मानें comparable instance chosen objective पर representative mix के 220 origin requests/second सँभालता है। Peak 440 है। गुणा provisional budget है, measured linear scaling नहीं। Table एक instance हटाती है, पूरा host या availability zone नहीं।
तीन instances nominal 660 देते हैं, एक खोने पर 440:peak बराबर, spare नहीं। चार nominal 880, एक खोने पर 660, target का 1.5 गुना। एक machine पर चार रखने से independent failure domains नहीं बनते। जिस host/zone loss को सहना है, उसे test करें।
| Instances | Nominal req/s | एक खोने पर req/s | 440 peak से तुलना |
|---|---|---|---|
| 2 | 440 | 220 | Loss के बाद 220, peak से कम |
| 3 | 660 | 440 | 440 peak बराबर, reserve नहीं |
| 4 | 880 | 660 | 660 provisional headroom |
DB writes, pool connections, cache/lock contention, payment/courier quotas, network और background work पहले system ceiling बना सकते हैं। एक tier बचाकर दूसरे को flood न करें। Backpressure, bounded work और operation ownership रखें; deferred jobs को भी freshness target और recovery budget चाहिए।
NGINX least_conn active connections और weights देखता है, पूरा business cost नहीं। Least-outstanding-request algorithm उससे समान नहीं। Long connections, multiplexing, request mix और limits चुनाव बदलते हैं। Real workload पर तुलना करें; round robin अपने आप ग़लत नहीं।
पहले response के खोने पर upstream retry effect दोहरा सकती है। NGINX retry rules दूसरे attempt की सीमाएँ बताती हैं; method label/proxy setting application idempotency की जगह नहीं। Payment errors पर अंधाधुंध POST retry न करें। Durable identity, unknown-result query और permitted retries पर bounded backoff/jitter, age/attempt limits तथा owner रखें।
Business promise बचाने वाली जगह admission/rate control, readable status और सुरक्षित वापसी दें। Unbounded queue से customer को failed बताने के बाद success न हो। Queue age में eligible ready work गिनें, intentionally future schedule नहीं। Accepted/pending/completed orders, reservations, captured payment और delivery अलग रखें।
Arrival, active work, recovery backlog और minimum failure capacity अनुमति दें तभी scale-in करें। Drain और termination supervise करें; owned work पूरा होने दें या सुरक्षित recover करें, reconciliation evidence रखें। Event समाप्ति timer से payment/fulfilment obligations समाप्त नहीं होतीं।
Test से पहले business success, error/timeout limits और latency objectives तय करें। Browse, search, variants, cart, login और authorised checkout fixtures वास्तविक अनुपात में लें, साथ में cache misses/retries । External effects रोकें ताकि rehearsal real customer charge या dispatch न करे।
k6 open और closed workload models अलग करता है। Step-arrival सवाल में slow response offered demand चुपचाप न घटाए। Arrival-rate iteration में कई requests हो सकती हैं; actual sent/completed rates, dropped iterations और generator capacity देखें, केवल configured VUs नहीं।
Target step, sustained peak, उचित higher scenario, cold/revalidation, instance loss और safe scale-in test करें। Tail latency, business outcomes, admitted/rejected work तथा per-tier waits लें। Agreed limits और operator/kill path रखें; CPU guard अकेले duplicate charges नहीं पकड़ता। एक material constraint बदलें, relevant scenario फिर चलाएँ।
Midnight example की तैयार team दिखा सकती है कौन पहले ready, failure के बाद क्या बचता है और overload कैसे सँभलेगा। पूरा 440-request mix objective मानता है या नहीं, integrated test बताएगा। StoreConsole सहित supplier से actual offered version, modules और deployment में यही evidence माँगें।
समीक्षा 5 नवंबर 2026 । अनिचुर रहमान, StoreConsole के निर्माता। Traffic, timing, memory और capacity planning examples हैं, किए गए tests या guaranteed product throughput नहीं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
