Crypto Exchange (Binance) ডিজাইন

আজকে আমরা একটা বড় ইন্টারভিউ প্রশ্ন ধরব — "Binance বা Coinbase-এর মতো একটা crypto exchange ডিজাইন করো।" এটা শুনতে যত সহজ, ভেতরে তত জটিল। কারণ একটা exchange আসলে দুটো একদম আলাদা জগৎকে জোড়া দেয়: এক দিকে off-chain একটা অসম্ভব দ্রুত matching engine (পুরোপুরি স্টক এক্সচেঞ্জের মতো), আর অন্য দিকে on-chain ব্লকচেইন যেখানে আসল কয়েন জমা আর তোলা হয়।

১. সমস্যা বোঝা (Requirements)

প্রথমে ঠিক করি আমরা কী বানাচ্ছি।

Functional requirements:

• ইউজার deposit করতে পারবে (যেমন BTC, ETH, USDT) — একটা deposit address-এ পাঠাবে।
• ইউজার spot trading করতে পারবে — limit ও market order দিয়ে BTC/USDT-এর মতো pair-এ কেনা-বেচা।
• একটা real-time order book ও সাম্প্রতিক trade দেখা যাবে।
• ইউজার withdrawal করতে পারবে — কয়েন বাইরের wallet-এ পাঠাবে।
• KYC ও account management থাকবে।

Non-functional requirements (এখানেই আসল চ্যালেঞ্জ):

• Correctness / Consistency: এক satoshi-ও যেন হারিয়ে বা ডাবল না হয়। Money কখনো "eventually consistent" হতে পারে না — এখানে strong consistency লাগে।
• Custody security: ইউজারের fund-এর দায়িত্ব আমাদের। Key চুরি হলে সব শেষ।
• Low latency: matching engine-এ microsecond মাত্রার latency দরকার, কারণ high-frequency traders থাকবে।
• High availability: market কখনো বন্ধ হয় না (২৪x৭)।
• Auditability: প্রতিটি পয়সার গতিবিধি trace করা যাবে।

CAP theorem-এর কথা মাথায় রাখলে, money ledger-এ আমরা সবসময় Consistency বেছে নিই, Availability-র চেয়ে।

২. স্কেল আন্দাজ (Estimation)

একটা napkin math করি, যাতে আমরা বুঝি system-টা কত বড়।

ধরি:
- মোট registered user        = 50 মিলিয়ন
- Daily Active Users (DAU)    = 5 মিলিয়ন
- Peak trades / second (TPS)  = 100,000 (volatile market-এ)
- Order placement/cancel rate = trade-এর ~10x = ~1,000,000 ops/sec (peak)

Matching engine memory:
- প্রতি pair-এর order book RAM-এ থাকে
- ধরি 1,000 trading pair, প্রতি pair ~1M open order
- প্রতি order ~200 bytes -> 1,000 * 1M * 200B = ~200 GB
  -> pair-wise shard করে একাধিক server-এ ভাগ

Ledger storage (append-only):
- প্রতিদিন trade = 100k TPS * 86,400s (peak-adjusted ~avg 20k)
  -> ~1.7 বিলিয়ন trade/day
- প্রতি trade -> কয়েকটা ledger entry, ~500 bytes
  -> ~০.৮ TB/day raw, compress + archive করতে হবে

Blockchain deposit scan:
- প্রতি chain-এ প্রতি নতুন block scan -> hot path নয়, কিন্তু 24x7

মূল শিক্ষা: matching engine-কে in-memory ও sharded by pair রাখতে হবে, আর ledger হবে বিশাল append-only store।

৩. API ডিজাইন

# Account / Wallet
POST   /v1/deposit/address        # নির্দিষ্ট asset-এর deposit address দাও
GET    /v1/balances               # সব asset-এর available + locked balance
POST   /v1/withdrawals            # body: {asset, amount, toAddress} (2FA লাগে)

# Trading
POST   /v1/orders                 # body: {pair, side, type, price, qty}
DELETE /v1/orders/{orderId}       # order cancel
GET    /v1/orders?status=open     # নিজের open order
GET    /v1/orderbook?pair=BTC-USDT&depth=50   # public
GET    /v1/trades?pair=BTC-USDT   # public recent trades

# Real-time (WebSocket)
WS     /stream  -> subscribe: orderbook, trades, ownOrders, balances

লক্ষ্য করো — order placement REST, কিন্তু order book ও trade update WebSocket দিয়ে push করা হয়, কারণ polling দিয়ে real-time market দেখা অসম্ভব।

৪. ডেটা মডেল

মূল সিদ্ধান্ত: কোন data on-chain আর কোনটা off-chain।

Data	কোথায়	কেন
Order book, trades	Off-chain (RAM + DB)	দ্রুত, প্রচুর volume
User internal balance	Off-chain (ledger DB)	Trade-এর সময় instant update
Deposit/withdrawal tx	On-chain (blockchain)	আসল কয়েন চলাচল
Custody key material	HSM / cold storage	কখনো DB-তে plaintext নয়

কয়েকটা মূল table:

Table	মূল কলাম
accounts	account_id, user_id, kyc_status
wallets	wallet_id, account_id, asset, deposit_address
ledger_entries	entry_id, account_id, asset, amount(+/-), type, ref_id, created_at
orders	order_id, account_id, pair, side, type, price, qty, filled_qty, status
trades	trade_id, pair, maker_order, taker_order, price, qty, ts
withdrawals	id, account_id, asset, amount, to_address, txid, status

ledger_entries হলো double-entry: প্রতি trade-এ অন্তত দুই entry — একজনের asset কমে, আরেকজনের বাড়ে, sum সবসময় শূন্য।

৫. হাই-লেভেল ডিজাইন

মূল component-গুলো:

• API Gateway / Auth: rate limit, 2FA, request validation।
• Order Management: order validate করে, fund lock করে, তারপর matching engine-এ পাঠায়।
• Matching Engine: in-memory, single-threaded per pair, price-time priority। ইনপুট order, আউটপুট trade event।
• Ledger Service: trade event consume করে double-entry ledger-এ লেখে, balance update করে।
• Wallet / Custody Service: deposit address তৈরি, withdrawal sign, hot/cold wallet ম্যানেজ।
• Blockchain Nodes: নিজস্ব full node (Bitcoin, Ethereum, ...) — deposit scan ও tx broadcast।
• Indexer: নতুন block scan করে deposit খুঁজে বের করে।
• Cache + DB: order book snapshot cache, ledger ও order PostgreSQL-এ।
• Message Queue (Kafka): matching engine আর ledger-এর মাঝে durable event stream।

Trade flow (সংক্ষেপে):

1. User order দেয় → Order Management fund lock করে (available কমে, locked বাড়ে)।
2. Order সংশ্লিষ্ট pair-এর Matching Engine-এ যায়।
3. Match হলে trade event Kafka-তে যায়।
4. Ledger Service double-entry লেখে, balance settle করে।
5. WebSocket দিয়ে order book + trade সবাইকে push হয়।

মনে রাখো: matching engine শুধু "কে কার সাথে কত দামে match" সেটা ঠিক করে — আসল কয়েন কোথাও যায় না। শুধু internal ledger বদলায়। আসল blockchain transaction হয় শুধু deposit আর withdrawal-এর সময়।

৬. গভীরে (Deep Dive)

৬.১ Custody ও Key Security (hot vs cold wallet)

এটাই exchange-এর সবচেয়ে স্পর্শকাতর অংশ। আমরা ইউজারের আসল কয়েন রাখি, মানে private key আমাদের হাতে।

• Hot wallet: online, internet-connected। শুধু 5-10% fund এখানে রাখা হয়, যাতে withdrawal দ্রুত হয়। Private key থাকে HSM (Hardware Security Module)-এ, কখনো plaintext-এ নয়।
• Cold wallet: পুরোপুরি offline (air-gapped)। বাকি 90%+ fund এখানে। Withdrawal-এর জন্য সাধারণত multisig — যেমন 3-of-5 — একাধিক ব্যক্তি আলাদা ভৌগোলিক জায়গা থেকে approve করলে তবেই sign হয়।

Hot wallet-এ fund কমে গেলে cold থেকে periodic top-up হয়, আবার hot-এ বেশি জমলে cold-এ সরিয়ে নেওয়া হয় (rebalancing)।

৬.২ Deposit Flow ও Blockchain Confirmation

1. User-কে একটা unique deposit address দেওয়া হয় (প্রতি user প্রতি asset)।
2. User বাইরে থেকে কয়েন ওই address-এ পাঠায়।
3. আমাদের Indexer প্রতিটি নতুন block scan করে দেখে কোনো watched address-এ fund এসেছে কিনা।
4. Transaction পাওয়া গেলে সাথে সাথে credit নয় — আমরা N confirmation-এর জন্য অপেক্ষা করি।

কেন confirmation? কারণ একটা সদ্য তৈরি block reorg হয়ে বাতিল হতে পারে, বা double-spend হতে পারে। N-টা block তার ওপরে জমলে transaction কার্যত irreversible হয়।

সাধারণ confirmation নিয়ম (uneven, asset-ভেদে আলাদা):
- Bitcoin   : ~3-6 confirmation
- Ethereum  : ~12-35 confirmation (বা finality)
- বড় amount : আরও বেশি confirmation

Confirmation পূর্ণ হলে Ledger Service-এ একটা credit entry লেখা হয় এবং user-এর available balance বাড়ে।

৬.৩ Withdrawal Flow

1. User withdrawal request দেয় → 2FA + অনেক সময় email confirmation।
2. Risk engine চেক করে (নতুন address? অস্বাভাবিক amount? AML rule?)।
3. Internal ledger-এ balance প্রথমে debit + lock হয় (যাতে double-spend না হয়)।
4. Wallet Service hot wallet থেকে transaction তৈরি ও sign করে (HSM-এ)।
5. নিজস্ব blockchain node দিয়ে network-এ broadcast।
6. Txid পেলে status pending, confirmation পেলে completed।

বড় withdrawal হলে cold wallet থেকে manual/multisig approval লাগতে পারে। এই দুই ধাপ — internal ledger debit আর on-chain broadcast — কখনো atomic হয় না, তাই idempotency key ও reconciliation job দিয়ে মেলানো হয়।

৭. বটলনেক ও স্কেলিং

• Matching engine throughput: একটা single-threaded engine একটা pair সামলায় (determinism-এর জন্য)। Scale করতে pair-wise sharding — BTC/USDT এক server, ETH/USDT আরেক। In-memory বলে fast, কিন্তু crash হলে? তাই প্রতিটা input event Kafka-তে durable, restart-এ replay করে state rebuild হয় (event sourcing)।
• Blockchain latency: deposit/withdrawal-এর latency আমাদের হাতে নেই — confirmation network ঠিক করে। তাই UI-তে clear status দেখানো (pending, 1/6 confirmations) দরকার। এটা hide করার চেষ্টা করা ভুল।
• Indexing load: প্রতিটা chain-এ প্রতিটা block scan করা ভারী কাজ। একাধিক node, parallel scan, আর শুধু watched address filter করে এটা সামলানো হয়। Node lag হলে deposit credit-এ দেরি হবে।
• Hot/cold balance ব্যবস্থাপনা: hot wallet-এ fund শেষ হলে withdrawal আটকে যাবে। তাই auto-alert + scheduled cold-to-hot top-up। আবার hot-এ বেশি fund মানে বেশি ঝুঁকি — ভারসাম্য রাখাটাই কাজ।
• Ledger DB: append-only, প্রচুর write। Sharding (by account/asset) + read replica + cold archive দিয়ে scale করা হয়। Consistency-র জন্য balance update transactional।

৮. সারসংক্ষেপ

একটা crypto exchange আসলে দুটো system একসাথে: একটা off-chain, ultra-low-latency matching engine (ঠিক স্টক এক্সচেঞ্জের মতো) আর একটা on-chain custody system যা deposit/withdrawal সামলায়। মাঝে দাঁড়িয়ে থাকে একটা rock-solid double-entry ledger যা প্রতিটি satoshi-র হিসাব রাখে। নিরাপত্তার মেরুদণ্ড হলো hot/cold wallet split, HSM, multisig, আর deposit-এ confirmation নিয়ম।