Distributed SQL: কখন Spanner, CockroachDB ও YugabyteDB ব্যবহার করবেন

distributed SQL কী বোঝায়

distributed SQL এমন relational database architecture, যেখানে ডেটা ও transaction processing বহু মেশিনে ছড়িয়ে থাকে, কিন্তু অ্যাপ্লিকেশনের সামনে একটি লজিক্যাল SQL ডেটাবেস হিসেবেই দেখা যায়। এতে table, join, index, constraint ও ACID transaction থাকে, সঙ্গে স্বয়ংক্রিয় partitioning, replication এবং ব্যর্থতা পুনরুদ্ধার যোগ হয়।

সাধারণত নিচের বৈশিষ্ট্যগুলো থাকলে কোনো সিস্টেমকে এই শ্রেণিতে রাখা যায়:

• relational schema ও SQL query interface
• database node জুড়ে horizontal scaling
• partition জুড়ে transactional consistency
• স্বয়ংক্রিয় replication ও failover
• এক লজিক্যাল ডেটাবেস হিসেবে সমন্বিত কাজ

সংজ্ঞাটি গুরুত্বপূর্ণ, কারণ PostgreSQL বা MySQL-এ read replica যোগ করলেই তা distributed SQL হয় না। primary এবং replica-র কাঠামোয় write এখনও এক প্রধান server দিয়েই যায়। অ্যাপ্লিকেশন-নিয়ন্ত্রিত sharding write ছড়ায়, কিন্তু record কোথায় থাকবে এবং cross-shard কাজ কীভাবে চলবে তা অ্যাপ্লিকেশনকে ঠিক করতে হয়। distributed SQL এই দায়িত্বের বড় অংশ ডেটাবেসে নিয়ে যায়।

প্রচলিত RDBMS ও NoSQL-এর মাঝামাঝি অবস্থান

distributed SQL প্রচলিত RDBMS-এর relational programming model-এর সঙ্গে distributed data store-এর scale-out নকশা মিলিয়ে দেয়। primary instance write load সামলাতে পারলে এবং একটি region ব্যর্থ হলে অন্যত্র অবিরত write জরুরি না হলে প্রচলিত PostgreSQL ও MySQL ভালো কাজ করে। read replica, caching, connection pooling এবং ভালো index এই মডেলকে বহু বছর এগিয়ে নিতে পারে।

অনেক NoSQL ডেটাবেস join, transaction বা consistency guarantee সীমিত করে বণ্টন সহজ করেছে। বড় event stream, সহজে বাদ দেওয়া যায় এমন cache এবং বহু-row transaction-এ খুব কম জড়ানো record-এর জন্য তা এখনও যুক্তিযুক্ত। relational cluster-এ বেশি coordination লাগে, কারণ node-এ ডেটা ভাগ হলেও অ্যাপ্লিকেশন constraint ও transaction ঠিক থাকবে বলে আশা করে।

বাস্তব পার্থক্য জটিলতার মালিকানায়। manual sharding-এ application team routing বানায়, ডেটা rebalance করে, schema change সমন্বয় করে এবং কয়েকটি shard ছোঁয়া operation সামলায়। distributed SQL এই ব্যবস্থা দেয়, তবে engineer-দের network-ভিত্তিক সিস্টেমের জন্য schema ও query ডিজাইন করতেই হয়।

যে সমস্যাগুলো সমাধানের জন্য এটি তৈরি

distributed SQL তাদের জন্য, যাদের availability, ভৌগোলিক অবস্থান বা write বৃদ্ধির চাহিদা single-primary architecture ছাপিয়ে গেছে। উদাহরণ হিসেবে global SaaS service, অতিরিক্ত বিক্রি চলবে না এমন reservation system, আর এমন financial ledger যেখানে node ব্যর্থ হলেও নিয়ম অটুট থাকতে হবে।

এটি application-level sharding-এর প্রয়োজন কমাতে এবং এক write location-এর ওপর নির্ভরতা কমাতে পারে। ব্যবহারকারীর কাছে বা অনুমোদিত jurisdiction-এর ভেতরে ডেটা রাখতেও পারে। এর মূল্য আছে: বেশি replica, বেশি network traffic, বেশি coordination এবং এক server-এ না থাকা ব্যর্থতার ধরন।

কাজ যদি এক region-এ স্বচ্ছন্দে চলে, managed relational database-ই ভালো default। custom sharding, regional failover বা geographic data control যখন নিজেই বড় engineering system হয়ে দাঁড়ায়, তখন distributed SQL-এর খরচ সার্থক হয়।

ভেতরে ভেতরে distributed SQL কীভাবে কাজ করে

distributed SQL ডেটাকে replicated partition-এ ভাগ করে এবং consensus ও distributed transaction protocol দিয়ে পরিবর্তন সমন্বয় করে। SQL এই যন্ত্রপাতির বড় অংশ আড়াল করে রাখে, কিন্তু এর আচরণ latency, throughput, schema design ও incident response গড়ে দেয়।

partition নির্ধারণ করে record কোথায় থাকবে

একটি cluster তার logical table-কে এমন ছোট এককে ভাগ করে যা node-গুলোর মধ্যে আলাদাভাবে সরানো যায়। Spanner এগুলোকে split, CockroachDB range এবং YugabyteDB tablet বলে। প্রতিটি একক table বা index keyspace-এর অংশ জুড়ে থাকে।

partition boundary range, hash বা নির্দিষ্ট geographic rule মেনে হতে পারে। customer identifier অনুযায়ী সাজানো range সম্পর্কিত record scan করা সহজ করে, কিন্তু ক্রমাগত বাড়তে থাকা identifier নতুন write একটি partition-এ ঠেলে দিতে পারে। hash distribution write সমানভাবে ছড়ায়, তবে ordered scan বা tenant placement কঠিন হতে পারে। অনেক production schema tenant identifier-এর সঙ্গে আরেকটি value জোড়ে, যাতে সম্পর্কিত ডেটা হাতের কাছে থাকে কিন্তু সব write এক জায়গায় জমে না।

secondary index-এর নিজস্ব distributed storage লাগে। তাই একটি row-তে write করলে base table-এর সঙ্গে ভিন্ন partition-এ থাকা কয়েকটি index entry-ও বদলাতে পারে। এক server-এ সস্তা index cluster-এ বাড়তি consensus কাজ ও network traffic তৈরি করতে পারে।

replication ও consensus প্রতিটি partition রক্ষা করে

প্রতিটি partition-এ সাধারণত কয়েকটি replica থাকে এবং consensus group পরিবর্তনের স্বীকৃত ক্রম ঠিক করে। CockroachDB ও YugabyteDB Raft-ভিত্তিক replication ব্যবহার করে। Spanner তার time infrastructure-এর সঙ্গে Paxos-ভিত্তিক replication ব্যবহার করে।

leader বা leaseholder একটি replica group-এর write সমন্বয় করে। যথেষ্ট replica quorum গঠনের জন্য পরিবর্তনটি record করার পরই সিস্টেম তাকে committed ধরে। কোনো node হারিয়ে গেলে quorum থাকলে বেঁচে থাকা সদস্যরা নতুন coordinator নির্বাচন বা নির্ধারণ করতে পারে।

quorum গাণিতিক শর্ত, সব ব্যর্থতা ক্ষতিহীন থাকবে এমন প্রতিশ্রুতি নয়। তিন replica-র group সাধারণত একটি unavailable replica সহ্য করতে পারে। দুটি member হারালে অবশিষ্ট copy নিরাপদে write নিতে পারে না, কারণ অন্য কোনো majority অন্যত্র এগিয়েছে কি না তা প্রমাণ করা যায় না। replica count-এর মতোই failure domain জুড়ে placement গুরুত্বপূর্ণ।

distributed transaction কয়েকটি partition সমন্বয় করে

এক partition ছোঁয়া transaction অল্প coordination-এ শেষ হতে পারে। কয়েক partition জড়ালে সবার জন্য এক commit decision দরকার, যাতে প্রত্যেকে write প্রয়োগ করে অথবা বাতিল করে।

productভেদে protocol আলাদা, কিন্তু সাধারণত প্রাসঙ্গিক version পড়া বা lock করা, concurrent change যাচাই, intent বা provisional record replicate করা এবং শেষে commit নিশ্চিত করা লাগে। দীর্ঘ transaction conflict-এর সময়সীমা বাড়ায়। বড় batch বহু consensus group জড়াতে পারে এবং প্রতিটি statement সহজ দেখালেও latency spike ঘটাতে পারে।

তাই network-aware transaction design জরুরি। ডেটাবেস সমর্থন করলে সম্পর্কিত row-কে মিলযুক্ত partition prefix-এর নিচে রাখুন। transaction ছোট রাখুন, খোলা transaction রেখে external service-এর জন্য অপেক্ষা করবেন না এবং প্রভাব না মেপে হাজার হাজার অসংশ্লিষ্ট record এক atomic unit-এ নেবেন না।

সময় ও ক্রমের জন্য স্পষ্ট ব্যবস্থা দরকার

distributed node-গুলোর wall clock নিখুঁতভাবে সমলয় নয়, তাই transaction সাজাতে প্রতিটি product-এর নিজস্ব উপায় লাগে। Spanner TrueTime uncertainty bound ও commit wait দিয়ে external consistency দেয়। অন্য সিস্টেম physical clock-এর সঙ্গে logical component, dependency tracking এবং transaction protocol মেলাতে পারে।

clock coordination serializable execution, follower read ও snapshot-এর মতো কাজে প্রভাব ফেলে। আলাদা application server-এর তৈরি timestamp নির্ভরযোগ্য global order স্থাপন করে ধরে না নিয়ে অ্যাপ্লিকেশনের database transaction timestamp ব্যবহার করা উচিত।

locality নেটওয়ার্কের পথ নিয়ন্ত্রণ করে

locality configuration ঠিক করে replica কোথায় থাকবে এবং কোন region একটি record-এর write সমন্বয় করবে। উপযুক্ত replica caller-এর কাছে থাকলে read দ্রুত হয়। শক্তভাবে ordered write-কে quorum-এর প্রয়োজনীয় replica পর্যন্ত পৌঁছাতেই হয়, তাই latency নির্বাচিত topology অনুযায়ী হয়।

ভালো placement কোম্পানির নকশাচিত্র নয়, workload অনুসরণ করে। EU tenant-এর অধিকাংশ write যদি Europe থেকে আসে, তার write coordinator সেখানে রাখলে প্রতিটি transaction-এর শুরুতে আন্তঃমহাদেশীয় যাত্রা লাগে না। সব region থেকে আপডেট হওয়া global counter-এর মতো shared record কোনো writer-এরই সবসময় স্থানীয় হতে পারে না এবং contention তৈরি করতে পারে।

কখন distributed SQL সঠিক পছন্দ

geographic resilience, horizontal write capacity বা cross-partition correctness যখন অবিরাম coordination-এর খরচকে ন্যায্য করে, তখন distributed SQL উপযুক্ত। বড় কোম্পানির এটি স্বয়ংক্রিয়ভাবে লাগে না, আবার কঠোর regional availability প্রতিশ্রুতি থাকলে ছোট পণ্যেরও লাগতে পারে।

যে শর্তগুলো মূল্যায়নকে ন্যায্য করে

নিচের কয়েকটি শর্ত একসঙ্গে থাকলে গুরুত্ব দিয়ে মূল্যায়ন করুন:

• service-কে zone বা regional outage-এর মধ্যেও চলতে হবে
• write demand একটি primary database-এর বাস্তব সীমায় পৌঁছাচ্ছে
• manual sharding অ্যাপ্লিকেশন engineering-এর অনেক সময় নেবে
• node বা location জুড়ে transaction সঠিক থাকতে হবে
• record-এর জন্য কার্যকর geographic placement দরকার

এগুলো সংখ্যায় সমর্থিত হওয়া উচিত। প্রয়োজনীয় recovery time objective, recovery point objective, transaction latency, peak write rate এবং failure domain নির্ধারণ করুন। শুধু global scale-এর অস্পষ্ট চাহিদা architecture বাছার জন্য যথেষ্ট নয়।

বিভিন্ন region-এ user থাকাই চূড়ান্ত কারণ নয়। content-heavy অ্যাপ web server ও cache user-এর কাছে রাখতে পারে, কিন্তু এক database region বজায় রাখতে পারে। সামান্য পুরোনো ফল গ্রহণযোগ্য হলে read replica regional browsing সামলাতে পারে। কয়েক location-এর user-কে সম্পর্কিত ডেটায় কম latency-তে write করতে হলে যুক্তিটি শক্তিশালী হয়।

যে শর্তগুলো সহজ ডেটাবেসের পক্ষে

traffic মাঝারি, write এক region থেকে আসে এবং recovery-তে পরিকল্পিত database promotion চললে প্রচলিত relational service সাধারণত ভালো। এতে পরিণত tooling, বিস্তৃত extension compatibility, পরিচিত debugging ও কম infrastructure bill থাকে।

কঠোর latency চাহিদা local regional primary-কেও সুবিধা দেয়। দূরের region পেরোনো quorum write-এর চেয়ে local durable write অনেক দ্রুত শেষ হয়। analytics-নির্ভর সিস্টেমে operational transaction ও দীর্ঘ scan আলাদা করা ভালো, একই cluster উভয় কাজে সেরা হবে ধরে নেওয়া ঠিক নয়।

team capacity-ও গুরুত্বপূর্ণ। managed service hardware, patching ও control-plane কাজ কমায়, কিন্তু schema contention, transaction retry, query planning, capacity management বা application-side incident handling দূর করে না। ব্যর্থতার আচরণ পরীক্ষা করার সময় না থাকলে distributed database নেওয়া ঝুঁকি বাড়াতে পারে।

বিকল্পের ভিত্তিতে সিদ্ধান্তসীমা

সবচেয়ে শক্ত কারণ দেখা যায় যখন বিকল্পটি ইতিমধ্যেই জটিল। tenant routing, shard map, cross-shard transaction rule, regional promotion procedure ও আলাদা migration tooling বানাতে হলে, এসব সুবিধা দেওয়া ডেটাবেসকে গুরুত্ব দিয়ে দেখা উচিত।

বিকল্প যদি একটি managed PostgreSQL instance, একটি read replica ও পরীক্ষিত backup হয়, migration-এর জন্য পরিষ্কার প্রমাণ দরকার। আগে বর্তমান সিস্টেম benchmark করুন। CPU saturation হয়তো অদক্ষ query, দুর্বল connection management, অতিরিক্ত index বা অনুপস্থিত cache-এর ফল, horizontal write-এর প্রয়োজন নয়।

consistency, availability ও latency

distributed SQL সাধারণত ব্যর্থতার সময় প্রয়োজনীয় quorum-এ পৌঁছানো যায় না এমন operation প্রত্যাখ্যান করে transactional consistency বজায় রাখে। এতে committed state রক্ষা পায়, তবে network partition-এ কিছু request অপেক্ষা বা ব্যর্থ হতে পারে।

CAP ব্যর্থতার আচরণ বোঝায়

cluster-এর অংশগুলোর যোগাযোগ বিচ্ছিন্ন হলে CAP theorem প্রযোজ্য। প্রভাবিত ডেটার জন্য কোনো সিস্টেম একই সঙ্গে linearizable consistency এবং বিচ্ছিন্ন প্রতিটি দিক থেকে সফল response নিশ্চিত করতে পারে না। consistency-কেন্দ্রিক ডেটাবেস quorum-সহ দিকটিকে চলতে দেয় এবং অন্যত্র unsafe write প্রত্যাখ্যান করে।

CAP স্বাভাবিক চলার latency ব্যাখ্যা করে না। সব link কাজ করলেও replica-দের যোগাযোগ করতে হয়। engineering সিদ্ধান্তে partition-এ কী হবে এবং সুস্থ অবস্থায় অ্যাপ্লিকেশন কত coordination মেনে নেবে, দুটিই রয়েছে।

অ্যাপ্লিকেশনকে unavailable outcome স্পষ্টভাবে সামলাতে হবে। timeout, retryable transaction error ও write region সাময়িক হারানো স্বাভাবিক সম্ভাবনা। বিচ্ছিন্ন দুই region-ই success ফেরালে balance বা reservation-এর জন্য তা আরও খারাপ, কারণ reconciliation-এর নির্ভরযোগ্য স্বয়ংক্রিয় উত্তর নাও থাকতে পারে।

strong read ও ইচ্ছাকৃত stale read আলাদা

strong read অনুরোধ করা ordering guarantee-এর সঙ্গে সামঞ্জস্যপূর্ণ database state দেখে। কিছু product follower read বা bounded-staleness read দেয়, যা freshness কিছুটা কমিয়ে latency ও write coordinator-এর কাজ কমায়।

পছন্দটি পড়া field অনুযায়ী হওয়া উচিত। product description সামান্য পুরোনো replica থেকে পড়া যায়। সদ্য বদলানো password, বর্তমান account balance বা অবশিষ্ট inventory-এর জন্য উপযুক্ত strong বা session-consistent path দরকার। গতি বাড়াতে সব read-কে stale বলে service code-এ আবার correctness বানাবেন না।

বাস্তব driver ও routing layer দিয়ে read-your-writes পরীক্ষা করুন। update-এর পরের request ভিন্ন application server বা database endpoint-এ যেতে পারে। user যেন accepted change দেখে, তার জন্য session token, transaction boundary বা strong read setting লাগতে পারে।

isolation concurrent outcome নিয়ন্ত্রণ করে

transaction isolation ঠিক করে concurrent transaction কী ধরনের anomaly ঘটাতে পারে। serializable isolation সম্পন্ন transaction-গুলোকে এমন দেখাতে চায় যেন একবারে একটি করে চলেছে, যদিও database সেগুলো পাশাপাশি চালায়।

concurrent operation নিরাপদে সাজানো না গেলে serializable execution একটি participant বাতিল করতে পারে। এটি খারাপ ফল ঠেকানোর সুরক্ষা, database corruption নয়। অ্যাপ্লিকেশনকে পুরো transaction-জুড়ে সীমিত retry করতে হয়, write-কে প্রভাবিত করা প্রতিটি read-সহ।

ডেটাবেসের বাইরের retry idempotent হতে হবে। transaction নিশ্চিতভাবে commit হওয়ার আগে email পাঠানো বা payment provider-কে call করলে retry side effect পুনরাবৃত্তি করতে পারে। database transaction-এ outbox event লিখুন, commit করুন, পরে আলাদা worker external action পাঠাক।

দূরত্ব write latency-র ন্যূনতম সীমা ঠিক করে

cross-region transaction তার protocol-এর প্রয়োজনীয় message-এর চেয়ে দ্রুত শেষ হতে পারে না। quorum member-এর মধ্যে 80 millisecond round trip query execution, index maintenance, application work ও queueing-এর আগেই বাস্তব সময় যোগ করে।

এক user action-এ কয়েকটি sequential transaction প্রায়ই ব্যয়বহুল। checkout যদি order insert, inventory reservation, payment-state update ও audit write চারটি blocking commit-এ করে, network খরচ জমা হয়। এক atomic outcome ভাগ করা database change একত্র করলে অপ্রয়োজনীয় round trip কমে, আর external payment call খোলা transaction-এর বাইরে রাখা উচিত।

average নয়, percentile latency মাপুন। leader movement, contention, storage stall ও retry tail-এ দেখা যায়। সাধারণ rebalancing-এ p99 target মিস করলে median target মেটালেও user-এর কাছে ব্যর্থতা দৃশ্যমান হয়।

Spanner, CockroachDB ও YugabyteDB তুলনা

Spanner, CockroachDB ও YugabyteDB একই ধরনের distribution সমস্যা সমাধান করে, কিন্তু deployment model, compatibility, transaction implementation ও operational assumption-এ ভিন্ন। shared SQL label দেখে নয়, application behavior পরীক্ষা করে বেছে নিন।

Spanner managed Google Cloud কৌশলে মানায়

Spanner তাদের জন্য মানায় যারা managed Google Cloud database ব্যবহার করতে এবং তার dialect, topology ও operating model অনুযায়ী design করতে প্রস্তুত। TrueTime externally consistent transaction সমর্থন করে, অর্থাৎ documented semantics-এর মধ্যে committed transaction বাস্তব সময়ের ক্রম মেনে চলে।

এর PostgreSQL dialect SQL syntax-এর পার্থক্য কমাতে পারে, তবে dialect মানেই সম্পূর্ণ PostgreSQL equivalence নয়। extension, administrative function, system catalog, data type, driver ও ORM assumption এখনও যাচাই করতে হবে। বিদ্যমান application portable ধরে নেওয়ার আগে প্রতিটি database dependency তালিকাভুক্ত করুন।

চাহিদার system ইতিমধ্যেই Google Cloud identity, networking, observability ও regional control-এর ওপর নির্ভর করলে Spanner বিশেষ মনোযোগের যোগ্য। managed model database-node administration সরায়, কিন্তু schema design, query tuning, quota, cost management ও application recovery customer-এর দায়িত্বই থাকে।

CockroachDB PostgreSQL-কেন্দ্রিক distributed application-এ মানায়

CockroachDB এমন team-এর জন্য, যারা PostgreSQL-ধাঁচের application access চায় এবং range জুড়ে transactional data ছড়াতে চায়। এটি default হিসেবে serializable isolation ব্যবহার করে, তাই contention বা ordering conflict-এ প্রত্যাখ্যাত transaction ঠিকভাবে retry করতে হবে।

migration, driver ও ORM layer-এ compatibility পরীক্ষা করা উচিত। PostgreSQL extension ও বিশেষ আচরণ অনুপস্থিত বা ভিন্ন হতে পারে। এক-node execution plan নির্ভর query table ও index range-এ ভাগ হলে ভিন্ন আচরণ করতে পারে।

range movement ও automatic rebalancing capacity change সহজ করে, কিন্তু দুর্বল primary-key পছন্দ এখনও hot range তৈরি করতে পারে। multi-region abstraction table locality প্রকাশে সাহায্য করে, তবে কোন record regional, কোনটি global এবং write কোথায় coordinate হবে তা developer-দের ঠিক করতে হয়।

YugabyteDB YSQL ও mixed API চাহিদায় মানায়

YugabyteDB তাদের জন্য, যারা PostgreSQL-compatible relational interface চায় এবং আলাদা Cassandra-compatible API থেকেও লাভ পেতে পারে। YSQL relational table ও distributed transaction দেয়, আর YCQL ভিন্ন data model অনুসরণ করে, তাই প্রতিটি YSQL operation-এ যাওয়ার আরেক পথ হিসেবে দেখা ঠিক নয়।

এর storage layer tablet দিয়ে data distribute করে। table design, tablet splitting, index placement ও transaction scope কাজ cluster-এ কীভাবে ছড়াবে তা প্রভাবিত করে। PostgreSQL application-এও extension, function, tooling ও planner behavior-এর compatibility পরীক্ষা দরকার।

ভিন্ন deployment পদ্ধতি placement-এর নিয়ন্ত্রণ চাওয়া infrastructure policy-তে মানাতে পারে। self-managed হলে সেই নিয়ন্ত্রণের সঙ্গে customer-এর operational দায় আসে: upgrade, repair procedure, capacity, observability, certificate, backup ও failure test-এর মালিক লাগবে।

কার্যকর product test-এ application evidence লাগে

একই representative workload প্রতিটি viable product-এ চালান। schema creation, migration, ORM-generated SQL, transaction retry, backup restore, failover, scaling event এবং সবচেয়ে বেশি চলা query পরীক্ষা করুন।

শুধু peak transaction per second তুলনা করবেন না। p50, p95 ও p99 latency, conflict ও retry rate, region-জুড়ে transferred byte, storage amplification, restore time এবং simulated incident-এ operator effort লিখুন। সেরা পছন্দটি এমন, যা গ্রহণযোগ্য খরচ ও operational burden-এ correctness ও recovery target পূরণ করে।

regional user-সহ global SaaS

global SaaS application distributed SQL থেকে লাভ পায় যখন tenant-এর regional data placement এবং প্রতিটি geography-র জন্য আলাদা database stack ছাড়া transactional access দরকার। tenancy schema-তে স্পষ্ট হলে এবং বেশিরভাগ transaction এক tenant-এর মধ্যেই থাকলে নকশাটি ভালো কাজ করে।

tenant locality contract ও traffic অনুসরণ করুক

tenant identifier placement চালাতে পারে, যাতে European record অনুমোদিত European location-এ থাকে, আর অন্য customer-এর record তার চুক্তির দেশ বা region-এ থাকে। এতে এক logical schema বজায় রেখেও ভিন্ন physical policy মানা যায়।

placement rule শুধু base table-এর জন্য হলে চলবে না। index entry, change stream, temporary data, backup ও export করা record-এ regulated তথ্য থাকতে পারে। row এক জায়গায় আটকে রেখে global secondary index অন্যত্র পাঠালে কাঙ্ক্ষিত সীমা ভাঙতে পারে।

tenant isolation performance-কেও প্রভাবিত করে। বড় tenant shared partition ছাপিয়ে যেতে বা একটি node দখল করতে পারে। সেই tenant-এর ভেতরে hashing বা subpartitioning লাগতে পারে, তবে tenant-scoped transaction যেন কার্যকর থাকে।

regional read-এর freshness policy স্পষ্ট হওয়া চাই

read-heavy dashboard সামান্য দেরি গ্রহণযোগ্য হলে কাছের replica ব্যবহার করতে পারে। account change, authorization decision ও post-transaction confirmation screen-এ শক্ত আচরণ দরকার। এক global setting না নিয়ে freshness requirement অনুযায়ী query path আলাদা করুন।

প্রতিটি tenant-এর স্বাভাবিক writer অনুসারে write placement করুন। customer-এর staff প্রধানত Singapore-এ কাজ করলে তার write অন্য continent-এ coordinate করলে অপ্রয়োজনীয় latency হয়। tenant migration procedure-এ write হারানো, residency ভাঙা বা application cache-কে পুরোনো location-এ রেখে দেওয়া ছাড়াই placement বদলাতে হবে।

global application code-কে পরিবর্তন সহ্য করতে হবে

leader সরে, node restart হয়, maintenance-এ routing বদলায়। driver-এ যৌক্তিক timeout, retry policy, connection renewal ও transaction restart logic লাগবে। retry-তে jitter ও limit রাখুন, যাতে overloaded cluster একই সময়ে পুনরাবৃত্ত request-এর ঢেউ না পায়।

monitoring-এ region ও tenant class অনুযায়ী user latency আলাদা করুন। global average দূরের এক customer group-এর অতিরিক্ত network trip আড়াল করতে পারে। API span ও database statement যুক্ত করা trace identifier locality error খুঁজতে সাহায্য করে।

financial workflow ও ledger

financial workflow-এ database constraint ও transaction ব্যর্থতা এবং concurrent request জুড়ে ledger invariant বলবৎ রাখতে সাহায্য করে। distribution নিজে থেকে সঠিক accounting তৈরি করে না, তাই যে নিয়ম ভাঙা চলবে না তা schema-তে থাকতে হবে।

ledger-এ audit করা যায় এমন entry sequence রাখুন

append-oriented ledger এক balance value বারবার বদলে history মুছে না দিয়ে প্রতিটি movement entry হিসেবে রাখে। প্রতিটি posting-এ স্থায়ী transaction identifier, account, amount, currency, business timestamp ও creation metadata থাকা উচিত। debit ও credit posting unit-এ সমান কি না commit-এর আগে যাচাই করুন।

cached balance read দ্রুত করতে পারে, কিন্তু entry-র সঙ্গে একই transaction-এ বদলাতে হবে, নইলে স্পষ্টভাবে derived data হিসেবে রাখতে হবে। reconciliation job derived total ও source entry তুলনা করে history নীরবে না বদলে পার্থক্য জানাবে।

প্রতিটি account-এর জন্য global ordering খুব কমই দরকার। একটি account বা transfer pair-কে ছোঁয়া transaction-এ consistent order দরকার, কিন্তু অসংশ্লিষ্ট account পাশাপাশি চলতে পারে। এই সীমা ধরে design করলে এক global sequence বা settlement row-এর তুলনায় contention কমে।

idempotency retry নিরাপদ করে

payment API, queue ও webhook timeout-এর পর retry করে, তাই প্রতিটি business operation-এ স্থায়ী idempotency key লাগবে। সঠিক scope-এ, যেমন এক merchant বা account-এ, uniqueness বলবৎ করুন এবং এক database transaction-এ payment record ও ledger entry তৈরি করুন।

CREATE TABLE payment_attempts (
    account_id UUID NOT NULL,
    idempotency_key TEXT NOT NULL,
    provider_reference TEXT,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (account_id, idempotency_key)
);

দুই worker একই operation পাঠালে unique constraint ঠিক করে কোন insert সফল হবে। হারা worker-কে বিদ্যমান record পড়ে তার নির্ধারিত ফল ফেরত দিতে হবে। database transaction retry হয়েছিল বলে দ্বিতীয় provider charge করা যাবে না।

external call-এর জন্য transaction boundary দরকার

database এবং সম্পর্কহীন payment provider-কে একসঙ্গে atomically commit করানো যায় না, যদি না উভয়েই বিশেষ coordination protocol-এ অংশ নেয়, যা অধিকাংশ public API নেয় না। network call database transaction-এর বাইরে রাখুন এবং workflow-কে pending, authorized, captured, failed ও reversed-এর মতো স্পষ্ট state-এ মডেল করুন।

transactional outbox committed change downstream worker-কে publish করতে পারে। message একাধিকবার পৌঁছাতে পারে বলে consumer-কে event identifier দিয়ে deduplicate করতে হবে। এতে সব service জুড়ে অসম্ভব এক transaction দাবি না করেই পুনরুদ্ধারযোগ্য processing পাওয়া যায়।

hot account-এর আলাদা নকশা দরকার

payroll run, marketplace settlement ও বড় merchant একটি account-এ write জমাতে পারে। database node যোগ করলেও একটি conflicting row-কে তাদের মধ্যে ভাগ করা যায় না। immutable entry partition, per-period accumulator, এক account-এর জন্য queued posting বা যত্নে নির্ধারিত subaccount hierarchy বিবেচনা করুন।

বাস্তব skew distribution পরীক্ষা করুন। uniform synthetic traffic cluster প্রস্তুত দেখাতে পারে, কিন্তু production-এর একটি merchant বারবার serializable conflict ঘটাতে পারে। correctness আগে, তবে accounting rule যেখানে অনুমতি দেয় সেখানে data model-এ নিরাপদ concurrency প্রকাশ করুন।

inventory, booking ও reservation

কয়েক user যখন একই দুর্লভ বস্তু দাবি করতে পারে, তখন inventory ও booking system-এ authoritative allocation transaction দরকার। দ্রুত availability read browsing উন্নত করে, কিন্তু শেষ unit কে পাবে তা শুধু commit path-ই ঠিক করতে পারে।

conditional write overselling ঠেকায়

যথেষ্ট stock থাকলেই conditional update reserve করতে পারে। affected-row count দিয়ে application allocation সফল হয়েছে কি না বোঝে।

UPDATE inventory
SET available = available - 1
WHERE sku = $1
  AND available > 0;

statement-টি reservation record-এর সঙ্গে একই transaction-এ থাকা উচিত। আগে availability পড়ে পরে decrement করলে race তৈরি হয়, যদি isolation level ও predicate handling সিদ্ধান্তটি রক্ষা না করে। অতিরিক্ত সুরক্ষায় database constraint negative quantity প্রত্যাখ্যান করুক।

assigned seating-এ performance ও seat identifier-এর unique constraint একটি বিজয়ী reservation দেয়। hotel inventory প্রায়ই room-night বা inventory-pool date অনুযায়ী মডেল হয়, যাতে overlap করা stay একই capacity নিতে না পারে। contention-এর সঠিক এককটি business rule থেকেই আসে।

hold allocation ও payment আলাদা করে

temporary hold payment বা user confirmation চলাকালে inventory reserve করে। expiration time ও status রাখুন, তারপর conditional transaction দিয়ে confirmed reservation-এ রূপ দিন। expiration worker শুধু এখনও active hold ছাড়বে, কারণ confirmation ও expiration প্রতিযোগিতা করতে পারে।

শুধু wall-clock delay release নিশ্চিত করে না। worker থেমে যেতে পারে, queue পিছিয়ে যেতে পারে, region ব্যর্থ হতে পারে। sellable inventory হিসাবের query-তে expired status ধারাবাহিকভাবে ধরতে হবে, আর repair job বাদ পড়া hold ফেরত আনবে।

hold duration পণ্য ও capacity-র সিদ্ধান্ত। checkout-এর জন্য দশ মিনিট যুক্তিযুক্ত হতে পারে, কিন্তু rush-এর সময়ে এটি দুর্লভ inventory-র বড় অংশ আটকে দিতে পারে। নির্ধারণের আগে abandonment ও payment completion time মাপুন।

চরম contention সরলরেখায় scale হয় না

এক row-এর জন্য হাজার buyer প্রতিযোগিতা করলে replica বাড়িয়ে তাকে parallel করা যায় না। প্রতিটি সফল decrement-কে অন্যগুলোর তুলনায় ক্রমে আনতে হয়। admission control, queue, stock bucket বা আগে বরাদ্দ করা regional quota release-এর সময় database রক্ষা করতে পারে।

regional quota coordination কমায়, কিন্তু semantics বদলায়। Europe-এ unit অব্যবহৃত থাকলেও অন্য region sell out হলে quota সরানোর নিরাপদ উপায় বা সাময়িক imbalance গ্রহণের নিয়ম চাই। business যখন regional capacity reconciliation নির্ধারণ করতে পারে, তখনই এই পদ্ধতি ব্যবহার করুন।

উচ্চ প্রাপ্যতা ও disaster recovery

replica placement, spare capacity এবং application behavior নির্ধারিত service objective-এর সঙ্গে মিললে distributed SQL নির্বাচিত infrastructure failure-এর মধ্যেও service চালিয়ে রাখতে পারে। শুধু replication এই ফল নিশ্চিত করে না।

SLO-তে failure domain নির্দিষ্ট করুন

uptime target-এর সঙ্গে workload ও failure scenario থাকা চাই। service-কে একটি node, একটি availability zone না পুরো region টিকতে হবে নির্ধারণ করুন। শুধু recovery-র পর নয়, ঘটনার সময় গ্রহণযোগ্য error rate ও latency বলুন।

এক ভবনে তিন replica-র risk profile স্বাধীন zone-জুড়ে তিন replica-র থেকে আলাদা। multi-region topology বড় ঘটনার সুরক্ষা দেয়, কিন্তু quorum path দীর্ঘ করে এবং location হারালে traffic নিতে যথেষ্ট অবশিষ্ট capacity চায়।

recovery time objective বলে service কত দ্রুত ফিরবে। recovery point objective বলে কত committed data হারানো গ্রহণযোগ্য। synchronous quorum replication নির্দিষ্ট ব্যর্থতায় শূন্য committed-data-loss লক্ষ্য সহায়তা করতে পারে, তবে প্রয়োজনীয় replica ও application path পরিকল্পনামতো চললেই।

failover দৃশ্যমান application event তৈরি করে

leader বদলালে চলমান transaction বিঘ্নিত, connection বন্ধ ও latency বাড়তে পারে। application-কে retryable database outcome এবং স্থায়ী business error আলাদা করতে হবে। failed transaction-কে একটি একক হিসেবে restart করুন, শুধু শেষ statement আবার চালাবেন না।

failure-এর পর connection pool মৃত endpoint ধরে রাখতে পারে। health check, DNS behavior, load balancer, certificate validation ও driver topology discovery test plan-এ রাখুন। database সুস্থ থাকলেও application সেটিকে খুঁজে নাও পেতে পারে।

failure-পরবর্তী capacity স্পষ্টভাবে হিসাব করুন। তিন region স্বাভাবিক সময়ে 70 শতাংশ utilisation-এ চললে একটি হারালে তার কাজের জায়গা থাকে না। headroom রাখা খরচের, কিন্তু failover capacity ছাড়া topology তার ঘোষিত লক্ষ্য পূরণ করে না।

game day নকশা যাচাই করে

failure exercise-এ একটি node বন্ধ করুন, zone isolate করুন, regional connectivity ভাঙুন এবং একটি application endpoint সরান। error duration, transaction retry rate, latency percentile, queue growth ও operator response মাপুন।

গুরুত্বপূর্ণ topology, driver বা schema পরিবর্তনের পর এই exercise চালান। গত বছরের traffic-এ প্রমাণিত procedure data দ্বিগুণ হলে বা এক tenant প্রভাবশালী হলে ব্যর্থ হতে পারে। exercise-এর নিরাপদ অংশ automate করুন, যাতে প্রমাণ বার্ষিক manual event-এর ওপর নির্ভর না করে।

replication backup নয়

replica accidental delete, ত্রুটিপূর্ণ migration ও ক্ষতিকর application write বিশ্বস্তভাবে নকল করে। replication ধরতে না পারা logical damage থেকে backup ও point-in-time recovery রক্ষা করে।

restore drill-এ আলাদা পরিষ্কার environment বানান, checksum বা application invariant যাচাই করুন এবং মোট recovery time মাপুন। encryption key, access policy, schema version ও dependent configuration অন্তর্ভুক্ত করুন। objective-এর মধ্যে restore করা যায় না এমন backup যথেষ্ট recovery system নয়।

data residency ও compliance-কেন্দ্রিক architecture

distributed SQL tenant বা record group অনুমোদিত region-এ রাখতে পারে, কিন্তু compliance নির্ভর করে প্রতিটি copy, access path ও operational process-এর ওপর। database locality বৃহত্তর program-এর একটি control।

residency rule-এর সুনির্দিষ্ট সংজ্ঞা দরকার

ডেটা একটি দেশে থাকবে, এর মানে storage, processing, support access, backup, encryption key বা সবকিছু হতে পারে। এই ব্যাখ্যায় topology ভিন্ন হয়। legal counsel ও auditor-দের regulation এবং contract-কে পরীক্ষাযোগ্য technical control-এ রূপ দিতে হবে।

team-এর regulated field ও derived data-র inventory লাগবে। log, trace, search index, analytics export, support attachment ও message queue-তে primary table-এর একই personal information থাকতে পারে। database সীমিত রেখে raw payload global-এ export করলে কাঙ্ক্ষিত policy পূরণ হয় না।

data minimization design সহজ করতে পারে। global service-এর শুধু account identifier ও aggregate status লাগলে sensitive detail অনুমোদিত region-এ রাখুন এবং অন্যত্র সবচেয়ে কম অনুমোদিত representation দিন।

placement policy-তে lifecycle operation-ও থাকবে

live replica, temporary replica, backup, snapshot, change record ও restore environment কোথায় থাকতে পারবে policy-তে বলুন। rebalancing ও maintenance-এও একই সীমা মানতে হবে। সুবিধার জন্য emergency procedure যেন regulated data unapproved region-এ কপি না করে।

access control-এ geographic ও organizational limit দরকার। service identity-কে কেবল প্রয়োজনীয় table ও operation দিন। মানুষের production access log করুন, সম্ভব হলে সময়সীমাবদ্ধ রাখুন এবং review করুন। region-bound encryption key নিয়ন্ত্রণ বাড়ায়, তবে key availability ও disaster recovery-এর আলাদা design লাগে।

tenant relocation-এর নথিভুক্ত workflow থাকা উচিত। contract change, customer migration বা corporate restructuring-এ record jurisdiction বদলাতে হতে পারে। পুরোনো copy কখন মুছবে, backup কখন পুরোনো হবে এবং completion-এর প্রমাণ কী, process-এ তা থাকতে হবে।

global reporting-এ derived dataset লাগতে পারে

global dashboard raw customer data region জুড়ে scan করলে কঠোর placement-এর সঙ্গে বিরোধ হয়। regional processing স্থানীয়ভাবে অনুমোদিত aggregate হিসাব করে non-sensitive result কেন্দ্রীয় reporting store-এ পাঠাতে পারে।

aggregation rule যেন restricted record পুনর্গঠন ঠেকায়। ছোট group, free-text field ও বিস্তারিত dimension সরাসরি identifier বাদ দিলেও personal information প্রকাশ করতে পারে। তাই analytics governance-ও পরের reporting project নয়, architecture review-এর অংশ।

operational ও analytical workload-এ আলাদা system প্রায়ই ভালো। transactional database বর্তমান product state রক্ষা করে, আর region-scoped pipeline report-এর জন্য governed dataset তৈরি করে। এতে দীর্ঘ analytical scan latency-sensitive transaction থেকে দূরে থাকে।

খরচ ও performance পরিকল্পনা

distributed SQL একটি basic single-region database-এর চেয়ে ব্যয়বহুল, কারণ এটি redundant capacity রাখে এবং network জুড়ে কাজ coordinate করে। ব্যয়বহুল sharding কাজ সরালে বা operating premium-এর চেয়ে বড় ক্ষতি ঠেকালে বিনিয়োগটি যুক্তিযুক্ত।

compute ও storage-এ replication overhead থাকে

তিনটি পূর্ণ replica-সহ logical 2 TB dataset secondary index, temporary compaction space, backup ও metadata-এর আগেই প্রায় 6 TB replicated data হয়। প্রকৃত billing ও compression productভেদে বদলায়, তাই শুধু logical table size নয়, মাপা physical storage দিয়ে estimate করুন।

compute-কে normal work, consensus processing, rebalancing, backup activity ও failure headroom সামলাতে হবে। একটি partition hot হলে node throughput-এর বিনিময়যোগ্য unit নয়। workload ছড়াতে পারলেই capacity যোগ করে লাভ হয়।

index write work ও storage বাড়ায়। প্রতিটি secondary index-এর query value, update frequency ও geographic placement দেখুন। distributed cluster-এ unused index disk নষ্ট করে এবং প্রতিটি প্রভাবিত write ব্যয়বহুল করে।

network charge উল্লেখযোগ্য হতে পারে

replication replica location-এ write পাঠায়। cross-region query, change feed, backup ও application traffic আরও transfer যোগ করে। কয়েক region-এ active traffic এমন bill আনতে পারে যা single-region benchmark দেখায় না।

প্রতি transaction byte, replication factor, write rate, index amplification ও transfer-এর দিক estimate করুন। তারপর representative load run-এ provider billing data দিয়ে পরীক্ষা করুন। request count বড় payload ও background movement দেখায় না।

locality error খরচ ও latency দুটোই বাড়ায়। endpoint selection বা tenant placement-এর কারণে এক region-এর service বারবার অন্য region-এর coordinator query করতে পারে। distributed trace ও regional cost breakdown এই pattern দেখায়।

user journey জমা হওয়া latency প্রকাশ করে

আলাদা statement নয়, সম্পূর্ণ user action model করুন। checkout-এর জন্য প্রতিটি sequential database commit, strong read, external API call ও queue handoff গুনুন। critical path-এ মাপা regional round-trip time ও query execution percentile বসান।

ধরা যাক এক journey-তে দুই sequential quorum write আছে, প্রতিটিতে 90 millisecond network coordination যোগ হয়। application processing-এর আগেই প্রায় 180 millisecond লাগে। এক atomic decision ভাগ করা change একত্র করলে commit কমতে পারে, আর independent read parallel করলে পথ ছোট হয়।

load test-এ বাস্তবসম্মত contention ও payload size রাখুন। random identifier-এর benchmark নিখুঁতভাবে ছড়ালেও production write অল্প কিছু জনপ্রিয় tenant-এ যেতে পারে। leader change ও rebalancing অন্তর্ভুক্ত করুন, যাতে tail latency সাধারণ cluster operation প্রতিফলিত করে।

বাস্তব বিকল্পের সঙ্গে total ownership তুলনা করুন

তুলনাটি operations cost-হীন কাল্পনিক database-এর সঙ্গে distributed SQL নয়। নির্দিষ্ট বিকল্পের সঙ্গে তুলনা করুন: managed PostgreSQL, replica, sharding service, regional recovery, application routing এবং সেগুলো রক্ষার engineer।

migration work, training, observability, incident response, support plan ও exit cost ধরুন। managed operation infrastructure labour কমাতে পারে, আর self-management বেশি staffing-এর বিনিময়ে control requirement মেটাতে পারে।

সাধারণ financial model annual platform premium-কে expected outage loss, পিছিয়ে যাওয়া engineering work, compliance exposure ও regional latency-প্রভাবিত revenue-এর সঙ্গে তুলনা করতে পারে। অনিশ্চিত input-এ range ব্যবহার করুন এবং কোন assumption সিদ্ধান্ত বদলায় চিহ্নিত করুন। ফল যদি অবাস্তব বড় outage estimate-এর ওপর দাঁড়ায়, সহজ system-ই সম্ভবত উপযুক্ত।

schema ও application design pattern

distributed SQL schema ভালো চলে যখন access path স্বাধীন কাজ ছড়ায় এবং সম্পর্কিত transaction কাছাকাছি রাখে। single-node schema অপরিবর্তিত port করলে correctness থাকতে পারে, কিন্তু latency খারাপ বা contention তীব্র হতে পারে।

primary key distribution প্রভাবিত করে

ক্রমাগত বাড়তে থাকা primary key নতুন row এক range-এর শেষে পাঠাতে পারে। random identifier insert ছড়ায়, কিন্তু পুরোপুরি random distribution tenant scan বা regional placement ব্যয়বহুল করতে পারে। composite key প্রায়ই tenant বা bucket identifier দিয়ে শুরু করে এবং সেই group-এ sortable value রেখে এই লক্ষ্যগুলোর ভারসাম্য আনে।

transaction boundary অনুযায়ী prefix বাছুন। প্রায় সব operation tenant-scoped হলে tenant অনুযায়ী group করলে distributed work কমে। খুব বড় tenant-এর namespace-এর ভেতরে bucket লাগতে পারে, যাতে কয়েক partition একসঙ্গে write নিতে পারে।

table বড় হওয়ার পর primary key বদলাতে বড় data rewrite লাগতে পারে। migration-এর আগে বাস্তব skew দিয়ে candidate layout পরীক্ষা করুন। শুধু total throughput নয়, partition heat, transaction fan-out, index locality ও scan behavior দেখুন।

capacity-এর আগে contention পুনর্নকশা করুন

global counter, singleton configuration row বা একটি merchant balance অন্যথায় স্বাধীন request-ও serialise করতে পারে। সব transaction-কে একই value update করার যৌক্তিক শর্ত node বাড়িয়ে দূর করা যায় না।

সাময়িক aggregation গ্রহণযোগ্য হলে exact global counter-এর বদলে partitioned counter দিন। একটি row বারবার না বদলে configuration version করুন। monetary state-এ accounting invariant বজায় রেখে append-only entry বা স্বাধীন subaccount-এ concurrency খুঁজুন, correctness দুর্বল করবেন না।

দীর্ঘ read-modify-write transaction conflict বাড়ায়। প্রয়োজনীয় ক্ষুদ্রতম set পড়ুন, transaction-এর মধ্যে user interaction এড়িয়ে দ্রুত commit করুন। business work মিনিট নিলে কয়েকটি ছোট transaction-জুড়ে state machine হিসেবে রাখুন।

retry আচরণ application contract-এর অংশ

driver হয়তো individual statement retry করে বা application code-এ retryable error দেয়। পুরো transaction replay কোন layer-এর দায়িত্ব বুঝুন। partial replay stale decision ব্যবহার বা আগের read বাদ দিতে পারে।

retry loop-এ maximum attempt, randomized backoff ও instrumentation রাখুন। conflict type, affected operation, attempt count ও final outcome লিখুন। অসীম retry contention-কে লুকোনো latency-তে বদলায় এবং cluster overload করতে পারে।

business request-এ স্থায়ী identifier দরকার, যাতে অনিশ্চিত client response নিরাপদে যাচাই করা যায়। database commit হলেও response হারালে client-কে semanticভাবে নতুন request পাঠানোর বদলে প্রতিষ্ঠিত operation query করতে হবে।

schema change-এ production-scale rehearsal দরকার

distributed schema change দ্রুত metadata update করতে পারে, কিন্তু backfill ও index creation background-এ চলতে থাকে। এই job storage, network ও CPU খরচ করে এবং live write-এ প্রভাব ফেলে।

expand-and-contract migration ব্যবহার করুন। আগে compatible field বা table যোগ করুন, উভয় form-এ চলতে পারে এমন code deploy করুন, নিয়ন্ত্রিত batch-এ backfill করুন, read বদলান, verification-এর পর পুরোনো form সরান। rollback plan-এ নতুন version-এর লেখা data ধরুন।

production-সদৃশ volume ও regional topology-তে বড় migration পরীক্ষা করুন। ছোট staging cluster-এ দ্রুত শেষ হওয়া change production-এ ঘণ্টা নিতে পারে এবং customer traffic-এর সঙ্গে প্রতিযোগিতা করে। শুরুর আগে progress, pause control, disk headroom ও retry behavior monitor করুন।

adoption checklist ও proof of concept

কার্যকর proof of concept একটি representative workload-কে স্পষ্ট correctness, latency, resilience ও cost target-এর বিপরীতে পরীক্ষা করে। generic benchmark নির্দিষ্ট schema ও application কেমন চলবে তা বলতে পারে না।

বাস্তব সীমাবদ্ধতার workflow বাছুন

দুর্লভ item booking, ledger transfer post করা বা নির্দিষ্ট region-এ tenant provision করার মতো workflow নিন। এর production-ধাঁচের schema, query, transaction boundary, payload size ও traffic skew পুনর্ব্যবহার করুন।

পরীক্ষার আগে সাফল্য নির্ধারণ করুন:

• concurrency ও retry-তে সঠিক outcome
• region অনুযায়ী p50, p95 ও p99 latency
• failure headroom-সহ sustained peak throughput
• node ও regional fault-এ recovery behavior
• মাপা compute, storage ও network cost

safety margin arbitrary multiplier নয়, প্রত্যাশিত বৃদ্ধি ও failure capacity থেকে আসা উচিত। একটি region হারানো scope-এ থাকলে test-এর সময় বাকি location-কে redirected load নিতে হবে।

বাস্তবসম্মত application surface তৈরি করুন

API ও ছোট user interface transaction sequence, driver behavior এবং user-এর অনুভূত latency দেখায়, যা শুধু database tool ধরতে পারে না। Koder.ai চ্যাটে React interface, Go backend ও PostgreSQL baseline তৈরি করতে পারে। এর planning mode generation-এর আগে workflow নির্ধারণে সাহায্য করে, আর source code export engineer-দের candidate database-এর জন্য data layer বদলাতে দেয়।

তৈরি করা application-কে test scaffolding হিসেবে ব্যবহার করুন, database compatibility-এর প্রমাণ হিসেবে নয়। migration চালান, generated SQL দেখুন, official driver configure করুন এবং সচেতনভাবে transaction retry করুন। Koder.ai snapshot ও rollback application iteration রক্ষা করতে পারে, কিন্তু database backup বা restore drill-এর বিকল্প নয়।

Koder.ai deployment ও hosting-ও সমর্থন করে, তাই test application instance database region-এর কাছে রাখা যায়। এতে এক location থেকে benchmark না চালিয়ে পুরো request path মাপা যায়। environment-এ production record-এর প্রয়োজনীয় control না থাকলে test data synthetic রাখুন।

স্বাভাবিক চলা ও ব্যর্থতা দুটোই পরীক্ষা করুন

test-এ steady traffic, burst, hot partition, long-running query, schema change, backup work ও node replacement রাখুন। এরপর অনুমোদিত test environment-এ connectivity বিঘ্নিত করুন ও একটি failure domain সরান।

transaction abort, retry attempt, unavailable response, leader movement, queue depth, disk use ও regional transfer capture করুন। operator-কে কী করতে হয়েছে লিখুন। undocumented manual step প্রয়োজন এমন automatic recovery এখনও production-ready নয়।

আলাদা environment-এ backup restore করে application invariant যাচাই করুন। inventory-তে allocation stock ছাড়িয়েছে কি না দেখুন। ledger-এ balance পুনরায় হিসাব করে balanced posting যাচাই করুন। SaaS tenancy-তে placement ও access policy restore-এর পরও টিকে আছে নিশ্চিত করুন।

migration-এর আগে compatibility যাচাই করুন

database extension, stored procedure, trigger, data type, isolation assumption, ORM feature, reporting query, backup tool ও administrative script-এর inventory করুন। প্রতিটিকে compatible, replaceable বা blocking হিসেবে ভাগ করুন।

full-size copy বা generated dataset-এ representative migration চালান। backfill duration, change-data-capture lag, dual-running cost ও cutover time মাপুন। dual write হলে discrepancy কীভাবে ধরা হবে এবং কোন phase-এ কোন system authoritative, তা নির্ধারণ করুন।

shadow read production state না বদলে result তুলনা করতে পারে। timing difference ও ইচ্ছাকৃত stale query হিসাব করুন, যাতে প্রত্যাশিত variation corruption হিসেবে না ধরা হয়। transactional data-তে কোনো অজানা পার্থক্য cutover-এর আগে সমাধান করুন।

production readiness পর্যালোচনা করুন

production review-এ database operation, application retry, security, residency policy, cost ও incident response-এর মালিক নির্ধারণ করুন। dashboard, alert, runbook, capacity threshold, restore evidence ও rollback decision point অন্তর্ভুক্ত করুন।

শেষ সিদ্ধান্ত PostgreSQL বা MySQL-এ থাকাও হতে পারে। proof of concept সফল যখন তা নির্ভরযোগ্য প্রমাণ দেয়, এমনকি প্রমাণটি দেখালেও যে distributed option বর্তমান চাহিদার তুলনায় বেশি ব্যয়বহুল। চাহিদা গ্রহণকে সমর্থন করলে ধীরে migrate করুন, প্রতিটি ধাপ মাপুন এবং নতুন system বাস্তব load-এ প্রমাণিত না হওয়া পর্যন্ত পরীক্ষিত ফিরে যাওয়ার পথ রাখুন।