Interview Modeling: estimation থেকে API ও data model

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

• Traffic assumptions থেকে QPS/storage হিসাব
• API contract ও business invariant জুড়ে data model
• Indexes এবং idempotency key যৌক্তিক করা

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

Interview-এ ১০ লাখ DAU শুনে candidate ১০ লাখ QPS ধরে দশ cluster আঁকলেন। আবার order table-এ total float রাখলেন এবং duplicate request সম্পর্কে কিছু বললেন না। Estimation, API ও model একে অন্যের সঙ্গে সম্পর্কিত। Scale calculation choice justify করে; data model business correctness ধরে; API caller-এর retry ও error contract প্রকাশ করে। তিনটি আলাদা checklist হিসেবে করলে contradiction সহজে তৈরি হয়।

সহজ করে বুঝি

DAU × প্রতি user দৈনিক operation থেকে daily request, তারপর ৮৬৪০০ দিয়ে average QPS। Peak average-এর সমান নয়; assumed multiplier বা explicit burst workload দিন। Storage calculation record bytes × growth × retention, তারপর index/replica/backup overhead আলাদা। API resource, state transition, pagination, authorization এবং idempotency scope দেখাবে। Table columns access patterns ও constraints-এর উত্তর দেবে।

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

দোকানের দৈনিক customer থেকে cashier সংখ্যা অনুমান করা এবং প্রতিটি bill-এ কী লেখা হবে তা নির্ধারণ করার মতো। Door count, invoice format ও ledger আলাদা হলেও একই customer journey-কে সমর্থন করে; তাদের হিসাব মিলতে হবে।

নকশাটি দেখুন

flowchart LR
 R[User journeys] --> N[Traffic and retention assumptions]
 N --> C[Capacity estimate]
 R --> A[API and retry contract]
 A --> D[Data model and constraints]
 D --> I[Indexes by query]
 C --> P[Partition and cache choices]
 I --> P

Journey operations গুনে estimate হয়। API read/write shape model-এ unique key ও relation নির্ধারণ করে। Query pattern index বেছে দেয়। Capacity যদি এক relational database-এ যথেষ্ট হয়, প্রথমেই sharding বাধ্যতামূলক নয়। Data model বদলালে record size এবং query cost estimate-এ ফিরে যান। Numbers illustrative assumption হিসেবে diagram-এর পাশে লিখুন।

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

Laravel migration up-method fragment; orders-এর id,user_id,status এবং amount_minor আগে আছে ধরে নেওয়া হয়েছে। Tenant-aware order listing newest-first access pattern-এ composite index দেখানো হয়েছে। Unique operation_key scope user অনুযায়ী; same key different payload এলে application conflict policy করবে। Existing duplicate data থাকলে migration fail হতে পারে।

use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
Schema::table('orders', function (Blueprint $table) {
    $table->string('operation_key', 100);
    $table->unique(['user_id', 'operation_key']);
    $table->index(['user_id', 'created_at', 'id']);
});

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

Detailed schema concrete reasoning দেয় কিন্তু interview-এ প্রতিটি nullable field নিয়ে সময় ব্যয় অপ্রয়োজনীয়। Core entity ও invariant আগে। More index read দ্রুত করতে পারে, write/storage cost বাড়ায়। Sequential ID ছোট efficient key, random public identifier enumeration কমাতে সাহায্য করতে পারে কিন্তু authorization replacement নয়। Exact estimate-এর চেয়ে unit ও order-of-magnitude correctness জরুরি।

সাধারণ ভুল

• Average QPS-কে peak capacity বলা।
• Index, replica ও retained history storage বাদ দেওয়া।
• Idempotency key global না per-user scope হবে তা না বলা।

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

API POST create response 201, accepted async work 202 বা conflict 409—actual semantics অনুযায়ী বাছুন। Pagination stable ordering চায়। Delete data lifecycle ও audit retention আলাদা policy। Model discussion-এ unique constraint, foreign key এবং transaction boundary বলুন। Outbox event business update-এর সঙ্গে atomic কি না জিজ্ঞেস করুন। Calculation result-এর uncertainty range দেখালে false precision কমে।

মনে রাখুন

Estimation units দিয়ে, API caller contract দিয়ে এবং data model business invariant দিয়ে যুক্ত করুন; তবেই capacity choice grounded হয়।

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

এক লাখ DAU, প্রতিজন দিনে ২০ read ও ১ write assumption নিয়ে average/peak আলাদা হিসাব করুন। Order-create API-এর idempotency ও owner-only read contract লিখুন। সেই contract-এর তিন constraint ও দুই query index নির্বাচন করুন।

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

1. DAU থেকে সরাসরি QPS?

না। User activity frequency এবং time distribution দরকার। Daily total থেকে average, peak আলাদা অনুমান করুন।

2. সব storage overhead multiplier এক?

না। Index, replica, backup ও object version আলাদা growth behavior দেয়। Assumptions প্রকাশ করুন।

3. API আগে না schema?

Iteratively দুটোই। User operation ও invariants schema shape দেয়; model limitation API semantics বদলাতে পারে।

4. Unique key কেন DB-তে?

Concurrent request application pre-check পেরোতে পারে। Database constraint final invariant enforce করে।

5. সব column index করব?

না। Query pattern, selectivity ও write cost দিয়ে index justify করুন; execution plan দিয়ে validate করতে হবে।

আরও পড়ুন

• Laravel migrations
• PostgreSQL indexes