দিনে 100,000 order একটি business goal, server specification নয়। Peak workload হিসাব করুন, measured bottleneck সরান ও failure capacity test করুন।
লেখক
Anichur Rahaman
Daily order দ্বিগুণ, তাই মালিক দ্বিগুণ বড় server চান। কিন্তু checkout ধীর হয় শুধু product import ও finance report দুপুরের rush-এর সঙ্গে মিলে গেলে। Hardware বাড়লে উপকার হতে পারে; ভুল query, connection pool exhaustion বা memory contention ঢাকাও পড়তে পারে। দৃশ্যটি শিক্ষামূলক, কোনো গ্রাহকের পর্যবেক্ষিত ঘটনা নয়।
ভালো roadmap business promise-কে measured work-এর সঙ্গে মেলায়। একই 100,000 orders/day হতে পারে সারাদিন ছড়ানো global business, অথবা অল্প সময়ের sale। কোনো সার্বজনীন order count নেই যেখানে নির্দিষ্ট CPU, আলাদা Redis বা fleet কিনতেই হবে।
Accepted order, checkout attempt, visitor, dynamic request, DB transaction ও background job আলাদা। ব্যর্থ buyer, repeat request, import, webhook, report ও expensive search ধরুন। CDN-এ উত্তর পাওয়া static asset আলাদা path। Order বাড়ার আগেই conversion ও request/visit বদলাতে পারে।
উদাহরণ model, benchmark নয়। 100,000 accepted orders/day÷86,400 second≈1.16 order/second। ধরি, না-কেনা visitor-এর browsing-সহ পুরো দিনের customer traffic-এ প্রতি accepted order-এর অনুপাতে 20 dynamic origin request। তাহলে 2,000,000 origin request/day≈23.15 request/second। এটি প্রতিটি buyer-এর journey ঠিক 20 request—এমন দাবি নয়।
এই request-এর 15% যদি 15 মিনিটে আসে: 300,000÷900≈333.33 request/second ওই window-তে। এক-second burst আরও বেশি হতে পারে। একই stable interval-এ mean request residence 0.24 second হলে গড়ে প্রায় 333.33×0.24≈80 request outstanding। এটি 80 CPU core, PHP child বা DB connection নয়। একই boundary ও mean ব্যবহার করুন; এই হিসাবে p95 বসাবেন না।
Journey ঠিক করুন: shopper সঠিক variant reserve, ঠিক total, নির্বাচিত payment flow শেষ ও durable order reference পান কি না। Business-এর সঙ্গে latency/error/freshness objective নির্ধারণ করুন। সবার checkout 800 ms বা DB CPU 60%-এর নিচে হলেই pass—এমন নিয়ম নেই। দ্রুত error page সফল purchase নয়।
Incoming demand ও accepted throughput-এর পাশে route-specific p95/p99, error/timeout ও completed outcome রাখুন। যথাযথ denominator-এ failed attempt-ও ধরুন। CPU throttling, process memory/OOM, disk latency/space, connection wait/lock/slow-query contribution ও queue rate/retry/oldest ready-job age দেখুন। Future-scheduled job মানেই late নয়। Slow checkout-এ কোন resource/dependency অপেক্ষা করিয়েছে মিলান।
Measured load ও downtime risk মানালে এক host ভালো শুরু হতে পারে। শুরু থেকেই managed database-ও যুক্তিসংগত হতে পারে; কোনোটিই বাধ্যতামূলক নয়। শুধু web নয়, সব process-এর memory/CPU/storage/backup/access বাজেট করুন। Worker ও recurring কাজ supervision-এ রাখুন; temporary shell-এ process চালু রাখা reliable operation নয়।
PHP-FPM concurrent-request process limit নথিভুক্ত করে। Measured process memory, shared overhead, CPU ও downstream capacity থেকে limit নিন। Child বাড়িয়ে RAM/DB connection শেষ হতে পারে। OPcache compilation পুনরাবৃত্তি কমায়; preloading-এর নিজস্ব lifecycle আছে। নিশ্চিত 50% speedup নয়। Enabled behaviour, memory ও release invalidation দেখুন। Stale বা scope-leaking cache যোগ করার আগে repeat query/request-time কাজ profile করুন।
Import/image/report/AI job নিয়মিত checkout ক্ষতি করলে resource budget আলাদা বা পৃথক worker pool/host-এ নিন। Critical কাজে capacity ও bounded retry রাখুন। এক worker-এ long job চললে শুধু priority দিয়ে সেটিকে pre-empt করা যায় না। কিছু checkout decision acceptance-এর আগেই consistent থাকতে হবে। Queue-এ দিলেই business requirement যায় না; ইচ্ছাকৃত pending state মিথ্যা success থেকে আলাদা।
Database আলাদা করলে resource isolation বাড়তে পারে, সঙ্গে network/security/backup/monitoring দায়িত্বও। Cache/session/queue service-এর ব্যবহার অনুযায়ী persistence, eviction ও availability policy লাগে। Laravel supported scheduling/coordination option দেয়। 512 MB scheduler floor বা এক long-lived process সার্বজনীন সমাধান নয়। Supported execution mode ও unintended duplicate recurring work আটকানোর ব্যবস্থা বাছুন।
একাধিক web node-এ shared বা উপযুক্ত replicated session, durable upload ও compatible release/config লাগে। Disposable node-এ business data-র একমাত্র copy নয়। Eligible response-ই cache করুন; key-তে host/tenant, language ও অন্যান্য representation dimension ধরুন। Private/session-setting response shared cache-এ নয়, isolation প্রমাণ ছাড়া। Cache miss/stampede-এও controlled rebuild capacity লাগে।
PgBouncer pooling mode-এর semantics আলাদা। Transaction pooling backend connection চাপ কমাতে পারে, তবে session feature ও prepared-statement configuration-এ app compatibility চাই। এটি DB execution capacity বানায় না। Web/worker/report/migration/admin মিলে connection budget করুন; limit বাড়ানোর আগে pool wait/DB saturation মাপুন।
Replica stale-tolerant read নিতে পারে, সব current stock/payment decision নয়। PostgreSQL streaming replication default-এ asynchronous—lag হয়; heavy standby query recovery-র সঙ্গে conflict করতে পারে, replication-এরও cost আছে। Read replica মানেই safe failover বা independent backup নয়। Rendering/search/analytics আলাদা করুন measured demand ও operating cost সমর্থন করলে। Server rendering live request path-এ থাকতে পারে; স্বয়ংক্রিয় background নয়।
Authorised test environment-এ production-like data size/index, জনপ্রিয় variant, cache state, third-party delay ও background কাজ রাখুন। ছোট থেকে demand বাড়িয়ে sustained/burst test ও স্পষ্ট stop condition দিন। Personal data রক্ষা, real charge/customer mail/shipment বন্ধ রাখুন। Build/config ও কী test হয়নি লিখুন।
Grafana k6 open/closed load model আলাদা করে। Fixed-user test response ধীর হলে কম কাজ পাঠায়; flash-sale arrival-এর model নাও হতে পারে। Arrival-rate test-এ generator capacity ও dropped iteration/actual request metric দেখুন। Iteration scripted journey; সবসময় এক HTTP request বা order নয়। Attempted arrival, achieved throughput, outcome ও waiting work একসঙ্গে জানান; load dropped হওয়ার পর ভালো percentile একা নয়।
Intended degraded state test করুন: এক web node down, slow provider, cold cache বা worker restart। একটি বাকি node প্রয়োজনীয় load না সামলালে দুই node যথেষ্ট failover capacity নয়। Web process বাড়িয়ে DB contention বাড়তে পারে। একটি প্রমাণিত constraint বদলে একই meaningful test চালিয়ে তুলনা রাখুন। Homepage test দিয়ে universal 100,000-order certification নয়।
Business impact থেকে RPO/RTO ঠিক করুন—কত recoverable data gap ও service recovery time গ্রহণযোগ্য। Order-count stage দিয়ে নয়। Job fail, archive অসম্পূর্ণ বা inconsistent backup হলে nightly dump schedule একা সর্বোচ্চ 24 ঘণ্টার loss নিশ্চিত করে না। Actual recoverable point ও পূর্ণ business restore যাচাই করুন। Replica deletion-ও কপি করে; protected retention-এর বদলি নয়।
Compatible release, bounded graceful handover ও rehearsed recovery decision রাখুন। Blue/green routing destructive migration বা completed payment ফেরায় না। Shared session/lock বা active release file নির্বিচারে clear নয়। দেখুন secure-deployment guide ও recovery-testing guide। নিচের পুরোনো demonstration interface দেখায়; আপনার environment recover হবে—এমন প্রমাণ নয়।
Roadmap table decision gate, fixed order band নয়। Compute, storage/IO, replica, media/egress, monitoring, backup restore, standby capacity ও engineering/on-call মিলিয়ে total operating cost ধরুন। সস্তা server-এর failure path পরীক্ষিত না হলে চালানো ব্যয়বহুল হতে পারে। Component বাড়লে version/credential/recovery procedure-ও বাড়ে।
শুরুর দোকানে আগে দেখুন দুপুরের slowdown report, import, connection wait নাকি অন্য dependency থেকে। প্রমাণিত contention isolate করে একই mixed journey test ও order/stock/payment outcome মিলান। পরের কেনাকাটা evidence অনুযায়ী, “এই machine size-এ সব দোকানের এই daily order চলে” প্রতিশ্রুতি অনুযায়ী নয়।
StoreConsole-এর supported baseline-এর জন্য requirements ও installation docs দেখুন; তারপর enabled module/extension/operation validate করুন। Supported minimum capacity benchmark নয়। Test evidence ও পরের review-এর named owner রাখুন।
| সিদ্ধান্তের ধাপ | পরিবর্তনের কারণ | Acceptance-এর evidence |
|---|---|---|
| সহজ operated runtime | Load মানায়; failure exposure জানা | Mixed journey, monitored limit ও restored backup |
| Competing কাজ আলাদা | Report/import/job critical path ক্ষতি করছে | একই test উন্নত; খরচ/owner নির্দিষ্ট |
| Redundancy ও scale-out | Availability/capacity-তে বেশি node লাগে | Shared state ও degraded/release test pass |
| Specialised operation | Search/analytics/AI/data-র আলাদা constraint | Consistency/lag/retention/cost/recovery গ্রহণযোগ্য |
পর্যালোচনা 5 নভেম্বর 2026 । Anichur Rahaman StoreConsole-এর নির্মাতা। Rate ও দৃশ্য উদাহরণ; hardware tier বা capacity guarantee নয়।
লেখকের পরিচয়
Anichur Rahaman
পড়া চালিয়ে যান
