Private origin और blue/green switch पूरी कहानी नहीं। Capacity, compatible data change, worker handover और परखे हुए recovery path से release की योजना बनाएं।
लेखक
Anichur Rahaman
09:44 पर engineer से 10:00 की ticket sale से पहले email typo fix deploy करने को कहा जाता है। Login attempts भी बढ़ रहे हैं। यह शिक्षण दृश्य है, field report नहीं। 16 मिनट बाकी हैं; छोटा diff या दो green server icons सुरक्षित release सिद्ध नहीं करते।
सवाल सिर्फ़ जल्दी version switch करना नहीं। पुराने-नए components साथ चलें तो customer सही transaction पूरा कर पाएगा? काम खोए या दोहराए बिना recovery होगी? Cosmetic fix peak के बाद करना कभी ज़िम्मेदार निर्णय है।
Engineering for High Volume का अंतिम, part 5 । पिछले भाग: web capacity · queue और worker · data tier · observability।
OWASP Top10:2025 में broken access control, security misconfiguration और software supply-chain failures हैं। यह risk-awareness reference है, पूरा assessment या firewall सब ठीक कर देगा इसका प्रमाण नहीं। अगली layer से पहले customer/admin routes, background connections और outbound integrations का नक्शा बनाएं।
Public web traffic के आगे उचित edge protection रखें, origin listeners और IPv6 सहित alternate addresses सीमित करें। Intended edge-to-origin route authenticate और allowed hostnames validate करें। Provider-wide IP allowlist आपका account नहीं पहचानती। उदाहरणतः Cloudflare का global origin-pull certificate accounts में shared है; अपने account/hostname की binding को उपयुक्त अलग configuration चाहिए।
Database/cache सिर्फ़ authorised workloads से, administration controlled path और strong identity से। Private address खुद authorisation नहीं। Sibling apps सोचकर segment करें; shared alias का गलत container resolve होना routing/data-exposure failure हो सकता है, यहाँ वास्तविक incident का दावा नहीं। Health checks/observability को भी सीमित access चाहिए; “workers में कोई inbound नहीं” सार्वभौमिक नियम नहीं।
OWASP की वर्तमान TLS guidance TLS 1.3, जरूरत की compatibility के लिए सुरक्षित TLS 1.2 और deprecated protocols बंद करने को कहती है। सम्बंधित hops पर certificate/peer identity validate करें। Private subnet से plaintext अपने आप सुरक्षित नहीं। Same-host exception actual threat model में लिखें। Encryption access control का विकल्प नहीं।
CDN eligible public content cache और configured attack protection दे सकता है; हर flood नहीं सोखता और checkout cache सुरक्षित नहीं बनाता। Personalised/authenticated/cart/checkout/session-setting responses shared cache से बाहर रखें, जब तक स्पष्ट safe design separation सिद्ध न करे। एक visitor को दूसरे का session/account data न मिले—test करें।
Bot challenge/rate limits में वास्तविक journeys, accessibility, shared-IP customers और वैध API/webhook clients समझें। कुछ addresses से login burst जाँच का signal है, scalper का प्रमाण नहीं। Account/action limits भी लगें; edge compromised account नहीं सुधारता। Secrets image/log से बाहर, build/deploy credentials सीमित, supported dependencies patch और अलग protected backups का restore test करें।
Controlled pipeline में versioned artifact build करें, staging में test और वही promote करें; serving nodes पर अलग builds नहीं। Source revision, build/dependency inputs, approval, config version और release reference रखें। Secrets अलग और environment differences reviewed हों; समान code से staging/production समान नहीं होते।
Docker digest-based image identity समझाता है। Intended registry digest/platform pin करें। Multi-platform index और platform images के digests अलग हैं; हर local image ID एक प्रकार का identifier नहीं। Trusted build/provenance और verification भी चाहिए: digest malicious image को भी ठीक पहचानता है। Planned recovery window में पुराना compatible artifact/assets रखें।
Expand-and-contract: compatible shape जोड़ना, सुरक्षित migration, उपयोग switch, बाद में पुराना हटाना। phone को contact_phone बनाना हो तो rehearsed migration में नया field जोड़ें। सभी live writers/workers/integrations में compatible dual-write आने से पहले उस पर भरोसा न करें; rolling deploy के दौरान old-only writer कुछ समय रहता है।
Bounded restartable batches, stable progress और concurrency-safe update से backfill करें। पुराने snapshot से नया customer edit overwrite न करें। Null सहित actual old/new values reconcile करें, सिर्फ़ row count या “नया field खाली नहीं” पर्याप्त नहीं। Locks, WAL, replica lag, disk और business latency देखें; measured safety limits पर pause करें।
PostgreSQL 18 ALTER TABLE documentation rewrite और locking अलग बताती है। तेज add-column भी lock माँग या transaction के पीछे wait कर सकता है। Nullable का अर्थ lock-free नहीं। Exact statement/workload rehearse, उचित lock/statement timeouts और stop/recovery plan रखें।
उदाहरण:2,400,000 rows÷5,000=480 batches। हर batch assumed 2 seconds तो 960 seconds यानी 16 मिनट processing। इसमें waits, throttling, retries और verification नहीं; यह completion forecast या no-impact प्रमाण नहीं। Convergence के बाद reads switch करें। पुराने web/worker/job/API dependencies और rollback window समाप्त होने पर बाद की approved window में contract करें।
दो nodes तभी उपयोगी redundancy हैं जब एक हटने पर बची capacity जरूरी load संभाले। शिक्षण उदाहरण: peak 900 requests/second, उसी tested mix में एक node 550 संभालता है। दो में से एक drain करने पर 350 requests/second की कमी। दो green nodes पर्याप्त प्रमाण नहीं। तीन हों तो एक हटने पर 1,100 बच सकते हैं; dependency bottlenecks और safety headroom फिर भी test हों।
Kubernetes rolling-update guidance availability/surge controls दिखाती है; हर platform पर ऐसे स्पष्ट निर्णय चाहिए। Capacity हो तो candidate शुरू, readiness/representative business behaviour verify, हटने वाले node पर नया काम रोकें और bounded in-flight work पूरा होने दें। Health endpoint ठीक हो सकता है जबकि checkout टूटा हो। Readiness, graceful termination और actual load-balancer propagation अलग checks हैं।
हर interruption proxy retry से न छिपाएं। NGINX non-idempotent requests का विशेष handling बताता है। Complete application/provider contract रोकता न हो तो ambiguous payment retry side effect दोहरा सकता है। Operation identity रखें, unknown query करें, bounded recovery दें। Long requests, WebSockets और browser asset/version compatibility संभालें। Public traffic से पहले भी candidate shared data/downstream को बदल सकता है।
Workers बदलने के लिए सामान्यतः पूरी queue खाली करना जरूरी नहीं। पुराने processes नए jobs लेना रोकें, tested grace में current work पूरा करें और supervised compatible replacements शुरू हों। Supported version window में payload/handler compatibility रखें। Database rollback भेजा email या charged payment वापस नहीं लेता।
Laravel 13 queue documentation graceful restart, supervision और timeout/retry संबंध बताती है। Configuration में restart/pause signals वास्तव में काम करें; interruption polling disabled हो सकती है। पर्याप्त shutdown time दें; execution timeout लागू retry/visibility सीमा से margin सहित छोटा हो। Duplicate delivery के लिए job effects सुरक्षित बनाएं। Force-kill के बाद काम चला ही नहीं यह न मानें।
Switch से पहले scheduler ownership/shared locks समन्वित करें। Laravel scheduling documentation shared-cache requirements वाले single-server/overlap controls बताती है। Scheduler “आखिर में” शुरू करना अकेला duplicate नहीं रोकता; एक scheduler process भी exactly-once effects नहीं देता। Missed runs, stale locks, long-running/sub-minute tasks देखें; जरूरत पर operation-level deduplication करें।
Blue/green में active और candidate साथ रहते हैं; acceptance के बाद routing बदलती है। वास्तविक switch में config validation, readiness, propagation और draining हैं; universal one-second rollback नहीं। खुले browsers के पुराने assets रखें और shared session/cache/API contracts दोनों versions से चलने की पुष्टि करें।
पहले failure decision लिखें: किन business/error/latency/queue-age signals पर promotion रुके, कौन तय करे, कौन version compatible रहे और data/external effects कैसे संभलें। Measured observation window रखें। 20% canary या पाँच मिनट soak हर जगह पर्याप्त नहीं; low-volume महत्वपूर्ण journey शायद उसमें आए ही न।
Destructive schema पुराने binary को अनुपयोगी कर सकता है। Code revert completed refund, हर backfill या dropped data वापस नहीं लाता। जरूरत अनुसार rehearsed forward repair, compatibility rollback या data recovery चुनें। Fresh dump recoverable business का प्रमाण नहीं; देखें recovery-testing guide। Production restore बाद के वैध transactions खो सकता है; reconciliation चाहिए।
Table evidence checklist है, guarantee नहीं। Representative authorised end-to-end tests में payment/email/shipment safely संभालें; HTTP status के साथ business outcomes मिलाएं। Named operator/escalation रखें। Exposure tests सिर्फ़ authorised infrastructure पर करें। Evidence से secrets redact करें, release ticket में copy नहीं।
09:44 पर compatibility/capacity/recovery evidence अधूरा हो तो typo fix रुक सकता है। सच में urgent security fix को explicit risk decision और rehearsed path चाहिए, automatic freeze exemption नहीं। Layers/techniques निर्णय testable बनाते हैं। “Zero downtime” तय scope पर मापा उद्देश्य है, दो servers या colour switch की दी हुई property नहीं।
| Gate | रखा जाने वाला evidence | Pause का कारण |
|---|---|---|
| Exposure | Intended hostname/edge accepted; गलत route denied | Alternate origin/data/admin path exposed |
| Artifact/config | Trusted tested digest/platform, reviewed config | Unknown build, secret leak, unsafe difference |
| Schema/data | सभी writers compatible; values reconciled | Locks, drift, destructive change, incomplete backfill |
| Capacity | Drain/failure state intended mix पर tested | बची capacity/dependency अपर्याप्त |
| Workers/scheduler | Compatible jobs, graceful handover, ownership/locks | Unknown effects, duplicate/missed recurring work |
| Recovery/acceptance | Named decider, business checks, compatible recovery | Recoverable state या effect reconciliation नहीं |
समीक्षा 5 नवंबर 2026 । Anichur Rahaman StoreConsole के निर्माता हैं। Scenes, rates और timings शिक्षण उदाहरण हैं, benchmark या audited production topology का दावा नहीं।
लेखक का परिचय
Anichur Rahaman
पढ़ना जारी रखें
