Checkout-এর Data Path সুরক্ষিত রাখুন: Pool, Replica, Cache ও Vector Search

শেখানোর একটি দৃশ্যে সকাল 9:02 । Report, document-index rebuild ও background job চলার সময় checkout ধীর। Connection dashboard ব্যস্ত দেখায়। বড় database কিনলে লাভ হতে পারে; আগে জানতে হবে request connection, row lock, disk নাকি কার্যকর CPU কাজের জন্য অপেক্ষা করছে।

Engineering for High Volume-এর part 3-এর মূল কথা: authoritative order path-এর নির্দিষ্ট resource ও consistency budget চাই। Cache, replica ও semantic index সাহায্য করবে; unavailable stock বিক্রি বা private record দেখানোর অজুহাত হবে না। এখানে কোনো customer benchmark বা ব্যক্তিগত load-test result দাবি করা হয়নি।

সমাধান বাছার আগে অপেক্ষার কারণ খুঁজুন

Offered ও completed business transaction, latency tail, pool wait, active/idle/idle-in-transaction session, long transaction, blocking lock, CPU, I/O, WAL ও maintenance pressure একসঙ্গে মাপুন। PostgreSQL connection limit finite slot রক্ষা করে এবং resource নেয়। Slot শেষ হওয়া নিজেই incident হতে পারে, শুধু নিরীহ symptom নয়। I/O wait ও parallel execution থাকায় চার vCPU মানেই কেবল চারটি query progress-এ থাকতে পারবে নয়।

নির্দিষ্ট interval-এ cumulative query cost ও call count দেখতে pg_stat_statements ব্যবহার করুন। Representative plan দেখতে EXPLAIN কাজে লাগে। ANALYZE statement চালায়; production-এ modifying বা expensive plan অসতর্কভাবে নয়। Rollback সব external বা nontransactional side effect ফেরায় না।

একটি list query ও 50 row-এর প্রতিটিতে আরেকটি relation query হলে সরল N+1 pattern-এ 51 query হয়। যথাযথ eager loading, index ও ছোট transaction সাহায্য করতে পারে; index-ও write ও storage খরচ বাড়ায়। বাস্তব data skew ও plan যাচাই করুন। Emergency resize যুক্তিসংগত mitigation হতে পারে। নতুন load test ছাড়া কখনো resize নয়—এমন absolute rule নয়। মাপা bottleneck ঠিক করে retest করুন।

একটি config line নয়, সব pool গুনুন

উদাহরণে তিন web node-এ 40 টি করে database client, 16 worker ও 4 operational client থাকলে, প্রত্যেকে এক connection খুললে potential demand 140 । এটি concurrent useful query বা TPS নয়। Pooling backend lease ভাগ করে; SQL, lock বা storage বিনা খরচে হয় না।

Database limit 150, emergency access-এর জন্য 10 এবং direct/maintenance-এর জন্য 20 budget ধরলে application budget 120 । এগুলো শেখানোর allocation, PostgreSQL setting-এর সুপারিশ নয়। PgBouncer configuration reference-এ ordinary pool user/database pair অনুযায়ী। Deploy/failover overlap-সহ প্রতিটি pooler, pair, reserve ও direct route যোগ করুন।

দুই pooler process × তিন active user/database pair ×20 ordinary backend =120 । ওই ছয় pool-এর প্রতিটিতে reserve 5 যোগ হলে application demand 150; অন্য 30 allocation-সহ 180, যেখানে limit 150 । Local pool cap global database cap নয়। এক pooler-এর database/user cap অন্য pooler instance-এর সঙ্গে ভাগ হয় না।

উদাহরণ allocation	Connection
Database ceiling	150
Emergency allocation	10
Direct/maintenance allocation	20
Application ordinary pools: 2×3×20	120
Additional pool reserve: 2×3×5	30
Reserve-সহ মোট: 120+30+20+10	180

আলাদা steady-state উদাহরণে 300 transaction/s × mean backend lease 0.04 s = গড়ে 12 leased connection । এটি max-pool recommendation বা 4,000 TPS promise নয়। Lease-এ transaction ধরে থাকার সময়ও আছে; long tail ও idle transaction ফল পাল্টায়। Wait, request deadline ও admission সীমিত করুন, নইলে pool শুধু অসীম queue অন্য জায়গায় সরাবে।

Pool mode application-এর চুক্তি

PgBouncer feature map-এ session, transaction ও statement pooling আলাদা। Session mode client session জুড়ে backend ধরে; transaction শেষে transaction mode ছাড়ে; statement mode multi-statement transaction মানে না। প্রয়োজনীয় behaviour দেখে বাছুন; transaction সব সময় দ্রুততম এমন rule নয়।

Mode বদলানোর আগে listener, session advisory lock, temporary object, setting ও driver test করুন। উপযুক্ত version ও nonzero max_prepared_statements-এ protocol-level prepared plan support থাকতে পারে; SQL PREPARE/DEALLOCATE আলাদা বিষয়। Compatibility table-এ NOTIFY ও LISTEN এক নয়।

পরের client-এ leak করতে পারে এমন session setting-এ tenant identity বা authorization রেখে দেবেন না। Scoped query ও database privilege কার্যকর করুন। ইচ্ছাকৃত transaction-scoped context সঠিকভাবে স্থাপন ও শেষ করতে হবে। Listener বা admin tooling-এর restricted direct/session route থাকতে পারে, নিজস্ব capacity ও security budget-সহ। প্রতিটি migration-এর unlimited bypass নয়।

Replica-র freshness contract ও recovery plan চাই

Business definition অনুমতি দিলেই lag-tolerant কাজ route করুন। Hot-standby documentation-এ read-only query ও recovery conflict আছে; long report cancel হতে পারে বা replay behaviour-এ প্রভাব ফেলতে পারে। Read replica মানে চিরতাজা, স্বাধীন বা unlimited analytics নয়।

এই design-এ authoritative stock reservation, payment state ও access decision primary-তে রাখুন। Read-after-write-এ primary route বা পরীক্ষিত consistency mechanism চাই। Measured freshness limit ও lag বাড়লে করণীয় নির্ধারণ করুন। Failed report অন্ধভাবে primary-তে পাঠালে checkout overload হতে পারে।

PostgreSQL replication documentation অনুযায়ী async streaming failover-এ acknowledged change হারাতে পারে। Sync option-এ latency/availability trade-off আছে; নির্দিষ্ট acknowledgement policy test করুন। Replica backup বা পূর্ণ HA system নয়। Promotion, পুরোনো primary fencing, routing ও recovery-তে drill-করা owner এবং RPO/RTO চাই।

মুছে ফেলা যায় এমন copy ও বাকি দায়িত্ব আলাদা করুন

Prefix ও logical database number key সাজায়; একই Redis/Valkey instance-এ আলাদা memory limit, eviction, persistence বা fault domain বানায় না। FLUSHALL logical database পেরোয়; ভুল prefix deletion-ও অন্য data নষ্ট করতে পারে। ভিন্ন policy-র role-কে যথাযথ controlled instance/service দিন, তারপর shared-host failure ও contention দেখুন।

Redis eviction documentation-এ noeviction limit-এ memory বাড়ানো write reject করে; queue correctness guarantee নয়। Rejected enqueue যেন visible ও recoverable business obligation থাকে। Valkey persistence documentation recovery option বোঝায়, tested durability বা restore-এর বিকল্প নয়।

Rebuildable cache-এর access pattern অনুযায়ী eviction বাছুন। LRU কাজ করতে প্রতিটি key-তে TTL লাগবেই নয়। Invalidation, tenant/currency/permission scope এবং bounded cache-miss concurrency দরকার। Session, revocation state ও queue payload-এর loss/expiry policy স্পষ্ট করুন; session eviction শুধু logout—এমন নয়। Critical accepted record ও publication intent durable রাখুন। Transient failure-এ backoff, age/attempt limit ও দায়িত্বসহ exception path দিন।

Role	যা স্পষ্ট চাই
Rebuildable cache	Scope, invalidation ও bounded cold-start load
Session / access state	Expiry, revocation ও loss-এর safe recovery
Queue / accepted obligation	Rejected publication, durability ও bounded recovery
Semantic index	Freshness, delete, recall ও current source permission

Actual product/version দেখুন: Redis 8 licensing-এ AGPLv3-এর পাশাপাশি RSALv2 ও SSPLv1 আছে; Valkey history-তে BSD lineage আছে। সব command, module ও managed service interchangeable ধরে নেবেন না। এটি compatibility reminder, licensing advice নয়।

Semantic relevance permission বা সত্যের বিকল্প নয়

একই PostgreSQL instance-এর দ্বিতীয় database-ও CPU, memory, I/O ও failure boundary ভাগ করে। Measured budget-সহ আলাদা instance/service শক্ত boundary দিতে পারে; operation ও synchronisation খরচও বাড়ে। প্রমাণ দেখে বাছুন; আলাদা database মানেই AI checkout ধীর করবে না—এমন promise নয়।

যেখানে উপযুক্ত, document embedding asynchronously বানান; authoritative source, revision/hash ও model/dimension metadata রাখুন। পুরোনো delayed job যেন নতুন revision overwrite না করে। After-commit dispatch record-to-enqueue gap মেটায় না; critical publication-এ atomic design বা recoverable outbox চাই। Delete, revoked access, re-embedding ও failed job সামলান; incompatible embedding space মিশিয়ে দেবেন না।

pgvector documentation-এ exact search ও HNSW/IVFFlat approximate index আলাদা। বাস্তব workload-এ recall, build memory ও query cost test করুন। Filtering-এ result কমতে পারে; compatible bounded iterative scan সাহায্য করে, যথেষ্ট result বা perfect recall guarantee নয়।

এক teaching query-তে অন্তত 10 eligible document আছে ধরুন। Exact filtered search-এর top 10-এর সঙ্গে approximate search-এর দশ eligible result-এর আটটি মিলে গেলে Recall@10 =8/10 =80%। এটি একটি উদাহরণ, measured service result নয়। নানা tenant/filter distribution, delete, empty result ও latency একসঙ্গে test করুন। দশটি result বানাতে authorization filter সরাবেন না।

Retrieval-এ entity/object permission দিন এবং snippet দেখানো বা result অনুসরণের আগে current source access আবার দেখুন। Index stock, delete ও permission change-এর পেছনে থাকতে পারে। Hidden title, embedding, cached result বা count leak নয়। Semantic suggestion থেকে আলাদা করে checkout authoritative current price/stock যাচাই করবে।

শান্ত dashboard নয়, failure path প্রমাণ করুন

Web node বদলানো গেলে image, invoice ও export-এর durable shared access চাই। Object storage একটি option; সঠিকভাবে পরিচালিত shared filesystem-ও হতে পারে। Placement latency, residency, recovery ও cost মেটাবে; সব সময় same region বাধ্যতামূলক নয়। CDN/public media ও protected document-এর access rule আলাদা। Streaming buffering কমাতে পারে, কিন্তু SDK/transform-এও buffer হতে পারে; actual peak মাপুন।

Cold cache, pooler loss, deploy overlap, DB failover, blocked write, rejected enqueue ও একই সময় vector rebuild দিয়ে planned mix test করুন। Real order outcome, privacy ও recovery backlog দেখুন। Maintenance ও failure-এর capacity রাখুন। Checkout সঠিকভাবে শেষ এবং delayed obligation recoverable record-এ থাকলেই সবুজ connection graph কাজে লাগে।

• Part 1: spike-এর আগে readiness
• Part 2: দায়িত্বসহ queue work
• Part 4: কাজে লাগার observability

পর্যালোচনা 5 November 2026 । আনিছুর রহমান, StoreConsole-এর নির্মাতা। Capacity ও recall-এর অঙ্ক teaching example; installed configuration বা measured performance নয়।