E-commerce: catalog, checkout ও order-এর নকশা

এই পাঠে যা শিখবেন

• Catalog ও checkout-এর আলাদা consistency বোঝা
• Order state এবং stock reservation design
• Payment ও notification side effect reliable করা

সমস্যা দিয়ে শুরু

দোকানে browsing দ্রুত, কিন্তু sale-এ শেষ product দুজন কিনে ফেলছেন। Requirement: catalog search, cart, checkout, payment status এবং order history। Recommendation ও marketplace payout প্রথম version-এর বাইরে রাখুন। Catalog কিছু stale হতে পারে, stock/payment correctness গুরুত্বপূর্ণ। User duplicate click, provider timeout এবং worker crash expected failure হিসেবে ধরুন। System boundary external payment provider পর্যন্ত atomic transaction নয়।

সহজ করে বুঝি

শুরুতে modular Laravel monolith যথেষ্ট: catalog, inventory, orders ও payment module আলাদা responsibility রাখবে। Cart tentative intent; confirmed order stock guarantee চাই। Transaction-এ stock reserve এবং pending order লিখুন, provider call transaction lock ধরে রেখে করবেন না। Order/payment state machine unknown outcome প্রকাশ করবে। Payment success provider-verified callback/reconciliation দিয়ে আসে; browser success page authoritative নয়।

পরিচিত একটি উপমা

বাজারে পণ্য দেখে basket-এ রাখা আর cashier-এর কাছে stock ধরে bill কাটা আলাদা। Cashier supplier-কে ফোন করছেন বলে stock খাতা দীর্ঘক্ষণ বন্ধ রাখলে সবাই আটকে যায়। সংক্ষিপ্ত reservation এবং পরে final confirmation বেশি কার্যকর।

নকশাটি দেখুন

flowchart TD
 U[Buyer] --> A[Laravel modules]
 A --> C[Catalog cache]
 A --> T[Inventory and order transaction]
 T --> D[(Relational database)]
 T --> O[Outbox]
 O --> W[Payment workflow]
 W --> P[External provider]
 P --> H[Verified webhook]
 H --> D
 D --> N[Queued notification]

Catalog cache browse cost কমায়। Checkout transaction authoritative inventory দেখে reservation এবং order তৈরি করে। Outbox durable pending work রাখে। Worker provider call করে, verified webhook state এগিয়ে নেয়। Notification order transaction commit-এর পরে dispatch হয়। Outbox relay retry হলেও unique operation key duplicate provider effect সামলাতে সাহায্য করে। Refund ও reservation expiry আলাদা transition।

PHP ও Laravel-এ প্রয়োগ

Assumption হিসেবে ৫ লাখ daily browse ও ১০ হাজার checkout নিন; ratio থেকে read path আলাদা optimize করুন, measured peak ছাড়া capacity claim নয়। POST /orders idempotency key নেয়; GET /orders/{id} owner-only। orders, order_items, inventory_reservations, payment_attempts এবং outbox_events table ভাবুন। নিচের fragment PostgreSQL/MySQL transaction, positive quantity, validated ownership এবং integer money ধরে stock-reservation-এর ক্ষুদ্র অংশ; full checkout নয়।

use App\Models\Product;
use App\Models\Order;
use Illuminate\Support\Facades\DB;
$order = DB::transaction(function () use ($productId, $userId) {
    $product = Product::query()->lockForUpdate()->findOrFail($productId);
    abort_if($product->stock < 1, 409);
    $product->decrement('stock');
    return Order::create([
        'user_id' => $userId,
        'product_id' => $product->id,
        'quantity' => 1,
        'status' => 'pending',
    ]);
});

সুবিধা, সীমাবদ্ধতা ও trade-off

Strong checkout transaction overselling কমায় কিন্তু hot product lock contention আনে। Reservation expiry inventory আটকে থাকার সময় সীমিত করে; late payment race সামলাতে হয়। Modular monolith development সহজ রাখে; independently scaling payment workload পরে extracted হতে পারে। Microservices দিয়ে শুরু করলে network failure ও distributed workflow আগে থেকেই যোগ হয়।

সাধারণ ভুল

• Cart-এ আছে বলে stock guaranteed ধরা।
• DB lock ধরে external payment call করা।
• Browser redirect দেখে order paid করা।

আরও একটু গভীরে

Stock display eventually consistent হলেও reservation invariant authoritative হতে হবে। Payment capture-এর পরে expiry worker stock ছেড়ে দিলে conflict হতে পারে, তাই transition conditional এবং transactional করুন। Checkout rate limit, authorization, audit এবং PII retention design করুন। Recovery drill-এ payment success কিন্তু local response lost, duplicate webhook এবং outbox backlog দেখুন। Business reconciliation technical retry-এর পরিপূরক।

মনে রাখুন

Catalog speed ও checkout correctness আলাদা goal; explicit reservation, payment state এবং reliable side-effect workflow নকশার কেন্দ্র।

নিজে চেষ্টা করুন

একটি শেষ product-এ concurrent checkout test লিখুন। Provider timeout-এর পরে retry, reservation expiry-এর পরে late webhook এবং duplicate callback-এর state table তৈরি করুন। কোন operation compensation চায় বলুন।

নিজের বোঝা যাচাই করুন

1. Cart stock reserve করে?

স্বয়ংক্রিয়ভাবে নয়। Product scope অনুযায়ী explicit reservation model দরকার; user intent আর inventory guarantee আলাদা।

2. Money float কেন নয়?

Rounding ambiguity এড়াতে fixed-scale decimal বা currency-aware integer minor unit ব্যবহার করুন। Currency precision স্পষ্ট রাখুন।

3. Paid state কে ঠিক করে?

Verified provider result ও reconciliation workflow। Browser-controlled success request বিশ্বাসযোগ্য authority নয়।

4. Outbox কেন?

Database commit ও background dispatch-এর gap সামলাতে durable work একই transaction-এ রাখে। Relay duplicate handle করতে হবে।

5. প্রথমে microservices?

Concrete scaling/team boundary দরকার না হলে modular monolith সহজ। Distributed failure-এর cost বিচার করে extraction করুন।

আরও পড়ুন

• Laravel database transactions
• Laravel queue transaction behavior