रोज़ 100,000 orders business goal हैं, server specification नहीं। Peak workload समझें, measured bottleneck हटाएं और failure capacity test करें।
लेखक
Anichur Rahaman
दैनिक orders दोगुने हुए तो मालिक दोगुना बड़ा server माँगते हैं। लेकिन checkout सिर्फ़ तब धीमा है जब product import और finance report दोपहर की भीड़ के साथ चलते हैं। Hardware मदद कर सकता है, या गलत query, connection pool और memory contention छिपा सकता है। यह शिक्षण दृश्य है, देखा गया customer case नहीं।
सार्थक roadmap business promise को measured work से जोड़ता है। समान 100,000 orders/day पूरे दिन फैला global काम या थोड़ी देर की sale हो सकते हैं। कोई universal order count नहीं जहाँ निश्चित CPU, अलग Redis या fleet जरूरी हो जाए।
Accepted orders, checkout attempts, visitors, dynamic requests, DB transactions और background jobs अलग हैं। न खरीदने वाले, retries, imports, webhooks, reports और महंगी search भी गिनें। CDN से मिले static assets अलग path हैं। Orders से पहले conversion/request-per-visit बदल सकते हैं।
उदाहरण model, benchmark नहीं। 100,000 accepted orders/day को 86,400 seconds से बाँटें तो लगभग 1.16 orders/second। मान लें पूरे customer traffic में, non-buyers सहित, प्रति accepted order का अनुपात 20 dynamic origin requests है। कुल 2,000,000/day, लगभग 23.15 requests/second। यह हर buyer का journey ठीक 20 requests होने का दावा नहीं।
इन requests का 15% अगर 15 minutes में आए तो 300,000÷900≈333.33 requests/second उस window में। One-second bursts अधिक हो सकते हैं। उसी stable interval में mean residence 0.24 seconds हो तो लगभग 333.33×0.24≈80 requests outstanding। यह 80 CPU cores, PHP children या DB connections नहीं। समान boundaries और means लें; p95 को mean की जगह न रखें।
Journey तय करें: सही variant reserve, सही total, चुना payment flow और durable order reference। Business के साथ latency/error/freshness objectives बनाएं। 800 ms checkout या 60% DB CPU universal pass mark नहीं। तेज error page सफल खरीद नहीं।
Incoming demand/accepted throughput के साथ route-specific p95/p99, errors/timeouts और completed outcomes देखें। उचित denominator में failed attempts भी हों। CPU throttling, process memory/OOM, disk latency/space, DB connection waits/locks/slow-query contribution और queue rates/retries/oldest ready-job age जोड़ें। Scheduled future job अपने आप late नहीं। Checkout की देरी actual waiting resource/dependency से मिलाएं।
Measured load और downtime risk स्वीकारें तो एक host अच्छी शुरुआत हो सकता है। शुरुआत से managed DB भी ठीक; कोई अनिवार्य नहीं। हर process की memory/CPU/storage/backup/access budget करें। Workers/recurring work supervised हों; temporary shell में process चलाना reliable operations नहीं।
PHP-FPM concurrent-request process limits बताता है। Measured process memory, shared overhead, CPU और downstream capacity से limit लें। Children बढ़ाकर RAM/DB connections खत्म हो सकते हैं। OPcache compilation बचाता है, लेकिन preloading का अपना lifecycle है; guaranteed 50% speedup नहीं। Enabled behaviour, memory और release invalidation जाँचें। Stale/scope-leaking cache से पहले repeated queries/request-time work profile करें।
Imports/images/reports/AI jobs बार-बार checkout को चोट दें तो resource budgets अलग या worker pool/host अलग करें। Critical work को capacity और bounded retries दें। अकेला worker long job में व्यस्त हो तो priority उसे pre-empt नहीं करती। कुछ checkout decisions acceptance से पहले consistent होने चाहिए। Queue करने से requirement नहीं मिटती; जानबूझकर pending state, झूठे success से अलग है।
DB अलग करने से isolation सुधर सकता है, लेकिन network/security/backup/monitoring दायित्व जुड़ते हैं। Cache/session/queue service के वास्तविक उपयोग के अनुसार persistence, eviction और availability policy रखें। Laravel supported scheduling/coordination options बताता है। 512 MB scheduler floor या एक long-lived process universal समाधान नहीं। Supported mode चुनें और unintended duplicate recurring work रोकें।
Multiple web nodes को shared/उचित replicated sessions, durable uploads और compatible release/config चाहिए। Disposable node पर business data की अकेली copy नहीं। सिर्फ़ eligible responses cache करें; keys में host/tenant, language और अन्य representation dimensions हों। Private/session-setting responses shared cache से बाहर, जब तक isolation प्रमाणित न हो। Cache miss/stampede में controlled rebuild capacity चाहिए।
PgBouncer pooling modes की semantics अलग हैं। Transaction pooling backend connections घटा सकता है, पर session features/prepared-statement configuration से app compatible हो। यह DB execution capacity नहीं बनाता। Web/workers/reports/migrations/admin का संयुक्त connection budget बनाएं; limits से पहले pool wait/DB saturation मापें।
Replica stale-tolerant reads के लिए है, हर current stock/payment निर्णय के लिए नहीं। PostgreSQL streaming replication default में asynchronous है; lag हो सकता है, heavy standby queries recovery से conflict कर सकती हैं और replication resources लेता है। Read replica अपने आप safe failover/independent backup नहीं। Rendering/search/analytics तभी अलग करें जब measured load और cost उचित हों। Server rendering live request path पर हो सकती है; हमेशा background नहीं।
Authorised environment में production-like data/index, popular variants, cache state, third-party delays और background work रखें। धीरे load बढ़ाएं, sustained/burst tests और stop conditions रखें। Personal data बचाएं, real charges/customer mail/shipments रोकें। Build/config और uncovered scope दर्ज करें।
Grafana k6 open/closed load models अलग करता है। Fixed-user test में response धीमा हो तो भेजा काम घट सकता है, जो flash-sale arrival नहीं दर्शाता। Arrival-rate test में generator provision करें और dropped iterations तथा actual request metrics देखें। Iteration scripted journey है, जरूरी नहीं एक HTTP request/order। Attempted arrivals, achieved throughput, outcomes और waiting work साथ बताएं; dropped load के बाद अच्छा percentile पर्याप्त नहीं।
Degraded state test करें: एक node unavailable, slow provider, cold cache या worker restart। बचा node जरूरी load न संभाले तो दो nodes पर्याप्त failover capacity नहीं। Web processes बढ़ने से DB contention बढ़ सकता है। एक justified constraint बदलें, वही meaningful test फिर करें और तुलना रखें। Homepage test से universal 100,000-order certification नहीं मिलता।
Actual impact से business RPO/RTO चुने: स्वीकार्य recoverable data gap और service recovery time। Order-count stage से नहीं। Job fail, incomplete archive या inconsistent backup होने पर nightly dump schedule अकेला अधिकतम 24 घंटे loss नहीं सुनिश्चित करता। Actual recoverable point और full business restore verify करें। Replication deletion दोहरा सकती है; protected retention का विकल्प नहीं।
Compatible releases, bounded graceful handover और rehearsed recovery decision रखें। Blue/green routing destructive migration/completed payment उलटती नहीं। Shared sessions/locks या active release files अंधाधुंध clear न करें। देखें secure-deployment guide और recovery-testing guide। नीचे पुराना demo interface दिखाता है, आपके environment की recovery साबित नहीं करता।
Table decision gates है, fixed order bands नहीं। Compute, storage/IO, replicas, media/egress, monitoring, backup restore, standby और engineering/on-call का total cost लें। सस्ता server बिना tested failure path महंगा चल सकता है। Components बढ़ें तो versions, credentials और recovery procedures भी बढ़ते हैं।
शुरुआती shop में पता करें कि lunch slowdown report, import, connection waits या अन्य dependency से है। Proven contention अलग करें, वही mixed journey test दोहराएं और order/stock/payment outcomes मिलाएं। अगली खरीद evidence से हो, एक machine size सबको निश्चित daily orders देगा इस वादे से नहीं।
StoreConsole baseline के लिए requirements और installation docs देखें, फिर वास्तविक enabled modules/extensions/operations validate करें। Supported minimum capacity benchmark नहीं। Test evidence और next review का named owner रखें।
| निर्णय चरण | बदलाव का कारण | Acceptance evidence |
|---|---|---|
| सरल operated runtime | Load फिट; failure exposure समझा | Mixed journey, monitored limits, restored backup |
| Competing work अलग | Reports/imports/jobs critical path बिगाड़ते | वही test सुधरा; cost/owner तय |
| Redundancy और scale-out | Availability/capacity को अधिक nodes चाहिए | Shared state और degraded/release tests pass |
| Specialised operations | Search/analytics/AI/data की अलग constraint | Consistency/lag/retention/cost/recovery स्वीकार्य |
समीक्षा 5 नवंबर 2026 । Anichur Rahaman StoreConsole के निर्माता हैं। Rates/scenes उदाहरण हैं; hardware tier या capacity guarantee नहीं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
