ব্ল্যাক ফ্রাইডে সেল60% পর্যন্ত ছাড়
  • বার্ষিক প্ল্যানে প্রথম বছর 60% ছাড়
  • লাইফটাইম লাইসেন্সে 45% ছাড়
শেষ হবে
অফারটি নিন

Exam Night প্রমাণ দিয়েছে, Capacity Guarantee নয় — NovaCommerce ৫

দুটি বাস্তব পরীক্ষা, একটি scale-in ভুল এবং planning model। শেষ পর্বে observation, অনুমান, operating cost ও বাকি test আলাদা করা হয়েছে।

লেখক

Anichur Rahaman

1 মাস আগে6 মিনিট পড়া223 দেখা
Exam Night প্রমাণ দিয়েছে, Capacity Guarantee নয় — NovaCommerce ৫

7 October 2026 পরপর দুটি পরীক্ষা চলে। Case record-এ একটিতে 661 start ও 638 submission, অন্যটিতে 439 start ও 425 submission ছিল। মাঝপথে pool minimum কমানো হলে serving node যথাযথ drain ছাড়াই সরে যায়; দুই মিনিটে প্রায় 360 request ব্যর্থ হয়। সচল service ও এই failure—দুটিই ফলাফলের অংশ।

NovaCommerce একটি course ও exam platform-এর গোপনীয়তা রক্ষার নাম। শেষ পর্বে September–October-এর observation রেখে প্রকাশিত arithmetic নতুন করে মিলিয়ে অপ্রমাণিত অংশ স্পষ্ট করা হয়েছে। এটি নতুন load test বা StoreConsole benchmark নয়।

Test যা চালিয়েছে, ফল সেভাবেই পড়ুন

25 September-এ IP-keyed limiter, 6 October run-এ Valkey connection failure এবং tested request mix-এ backend CPU saturation পাওয়া যায়। কারণ আলাদা, সমাধানও আলাদা। কিছু capacity pressure-এ server বাড়ানো কাজে আসে; ভুল identity বা shared service-এর বিকল্প নয়।

Record-এ frontend প্রায় 356 requests/s, p95 0.05 s, zero reported error; 5 October GET autoscale run-এ প্রায় 750 requests/s, zero server error/timeout কিন্তু প্রায় 4% HTTP 429; আর 25–500 ramp-এ zero application error হলেও 143 load-balancer error আছে। Mix ও scope আলাদা। সেরা সংখ্যাগুলো জুড়ে একটিমাত্র successful throughput claim করবেন না।

পরের guarded rollout-এ দুই seconds পরপর 219 probe-এ zero error ছিল। এটি sampled evidence; সব request, write বা long connection বেঁচেছে তার প্রমাণ নয়। Business-flow test-এ authenticated answer acceptance, durable receipt, safe retry ও final result যাচাই চাই; শুধু HTTP status বা cached homepage নয়।

বাস্তব সন্ধ্যা অন্য failure দেখিয়েছে

638/661 প্রায় 96.5%; 425/439 প্রায় 96.8%। এগুলো submission proportion, availability percentage নয়। না জমা দেওয়ার কারণ বিভিন্ন হতে পারে; count দিয়ে সব অনুপস্থিত submission technical failure বা zero data loss বলা যায় না।

Minute log-এ backend peak প্রায় 69 requests/s, provider-এর two-minute aggregation-এ 63। Reported average-এ pool CPU peak 47%, একটি node এক মিনিটে 86%। MySQL max CPU 24.5%, average 13.4%; worker max 46%, recorded failed job zero। Aggregation window ও denominator স্পষ্ট রাখুন। Zero failed job মানেই pending বা lost work নেই নয়।

পুরোনো CPU estimate প্রায় 59 ms/request। 63 requests/s-এ 3.717 CPU-seconds/s; আট vCPU দিয়ে ভাগে প্রায় 46.5%। 47%-এর কাছাকাছি হওয়া ওই assumption-এর consistency check; causation বা linear scale-এর প্রমাণ নয়। Scale-in incident readiness, per-node load ও retirement আলাদা করে পরীক্ষা করার প্রয়োজন দেখায়। Exam-hours runbook মানবনির্ভর control, enforced prohibition নয়।

পরের test বাছতে model ব্যবহার করুন

পুরোনো model-এ node-পিছু 50 backend requests/s, baseline 30 requests/s, imbalance factor 1.3, ছাত্র-পিছু opening request 15 এবং উপস্থিত অবস্থায় 0.025 requests/s ধরা হয়। একই request mix ও agreed latency target-এর জন্য 50 একটি hypothesis; universally safe limit নয়।

N healthy node-এ student budget N×50÷1.3−30 requests/s। Join window 600 seconds হলে student-পিছু 15÷600+0.025=0.05 requests/s; 120 seconds হলে 0.15। চার node-এ (4×50÷1.3−30)÷0.05≈2,477; নিচের teaching table-এ নামিয়ে 2,400। এটি fluid average model; burst, uneven arrival ও pause-এ limit ছাড়াতে পারে।

1.3 divisor এই planning factor; 30% idle capacity বা node failure coverage নয়। একটি node হারানোর scenario আলাদা মাপুন। কয়েক node-এর observed test ছাড়ানো row extrapolation, certified student capacity নয়। PDF upload, worker queue, database contention ও provider limit backend model-এর বাইরে। কম database CPU থেকে 450 requests/s ceiling বা ছয়গুণ headroom প্রমাণ হয় না।

Healthy backend nodeModel budget requests/s600-second join: rounded student120-second join: rounded student
2≈77900300
4≈1542,400800
6≈2314,0001,300

Architecture-এর সঙ্গে খোলা ঝুঁকিও লিখুন

পুরোনো design-এ আলাদা frontend/backend pool, প্রতিটিতে minimum দুই ও maximum দশ; primary/standby MySQL, shared Valkey, আলাদা PostgreSQL/pgvector, object storage এবং OpenSearch-এ backend log ছিল। Queue, scheduler, WebSocket ও SMS একটি fixed worker-এ। Worker failure point-ই ছিল; frontend log shipping ও standby planned।

Replicated database, stateless web node ও image নির্দিষ্ট recovery path উন্নত করে। সব dependency redundant, regional failure, bad deployment, unauthorized access বা ভুল delete থেকে সুরক্ষা নিশ্চিত করে না। Writer fencing ও restore আলাদা test করুন। নতুন write-এর পর frozen old copy current rollback নয়; image rollback-এর জন্যও schema, session ও queue payload compatible হতে হয়।

তুলনার আগে bill যোগ করুন

পুরোনো monthly web item $272: backend $112 +frontend $56 +worker $56 +দুটি balancer $48। Data/log $709: MySQL $389 +Valkey $240 +PostgreSQL $60 +OpenSearch $20। Snapshot $5 ও Spaces base $5 যোগে $991, variable usage-এর আগে। আগের “প্রায় $990” rounded ছিল, exact invoice নয়।

আগের $416 ছিল powered-off recovery Droplet-সহ web tier, পুরোনো full stack নয়। একই scope ও service assumption নিশ্চিত করে $416-এর সঙ্গে $272 তুলনা করুন; নতুন combined $991 নয়। Staff, support, tax, AI/SMS, overage ও rollout/peak capacity এই list-এ নেই; এটি total ownership cost বা current quotation নয়।

বর্তমান provider plan ও account eligibility দেখুন। তৃতীয় পর্বের MySQL Standard পরিবর্তনের কারণে পুরোনো pair-কে যাচাইহীন 2026 buying recipe করা যাবে না। Reliability-তে বেশি খরচ যুক্তিযুক্ত হতে পারে; savings বলার জন্য comparable service ও পুরো operating model চাই।

পুরোনো monthly groupListed subtotalScope
Web tier$2722 backend +2 frontend +worker +2 balancer
Data ও log$709MySQL +Valkey +PostgreSQL +OpenSearch
Snapshot ও storage base$10$5 +$5; usage আলাদা
Listed combined base$991Usage, staff, tax ও অন্য service বাদে

পরের acceptance gate এখনও বাস্তব কাজ

Record-এ formal multi-hour soak ও mixed write-path full load test planned ছিল। দুই ঘণ্টা exam observation controlled soak নয়। 24 ঘণ্টা local write না দেখায় memory leak, connection growth বা growing queue বাতিল হয় না। এগুলোকে চুপচাপ passed বলবেন না।

বড় event-এর আগে successful-answer ও latency threshold ঠিক করুন; representative identity ও arrival shape ব্যবহার করুন; duplicate submission ও deadline আচরণ পরীক্ষা করুন। Memory, connection, storage ও oldest-job age বোঝার মতো দীর্ঘ সময় চালান। Node failure, safe scale-in, database reconnect/failover, worker recovery ও backup restore নিন। Tool version, script, resource setting, error ও accepted-work reconciliation রাখুন। Disruptive test isolated representative environment বা অনুমোদিত window-তে stop criteria-সহ চালান।

এই সিরিজের reusable loop: business outcome মাপুন, constraint খুঁজুন, সেই layer বদলান, outcome ও recovery আবার test করুন। সবচেয়ে প্রয়োজনীয় জিনিস evidence register—যেখানে observed, modelled ও not yet tested স্পষ্ট থাকে।

Acceptance evidence map: outcome, arrival replay, সব failure count, capacity assumption পরীক্ষা, recovery/soak ও কাজ-খরচ reconciliation।
পরের evidence সংগ্রহের plan, test passed-এর দাবি নয়। Capacity row model output; cost table পুরোনো base spend।

সিরিজ

মূল তথ্যসূত্র

পর্যালোচনা: ৬ নভেম্বর ২০২৬। Anichur Rahaman, StoreConsole প্রতিষ্ঠাতা। পুরোনো observation রাখা, arithmetic যাচাই এবং extrapolation ও planned test আলাদা করা হয়েছে।

লেখকের পরিচয়

Anichur Rahaman

পড়া চালিয়ে যান