CQRS

একটি e-commerce-এ: একই product table-এ একদিকে admin update করছেন (write), অন্যদিকে millions of customer search করছেন (read)। এক table দুই purpose serve করতে গিয়ে — দুটোই ভোগে। CQRS বলে: "আলাদা করো — write-এর জন্য এক model, read-এর জন্য আরেকটি।"

CQRS কী?

CQRS = Command Query Responsibility Segregation। Software-এ write (command) এবং read (query) operations-কে আলাদা model + আলাদা data store-এ ভাগ করা।

কোথা থেকে এসেছে?

Bertrand Meyer-এর Command-Query Separation (CQS) principle থেকে inspired:

• Command: State change করে, value return করে না।
• Query: Value return করে, state change করে না।

Greg Young এই idea-কে architecture level-এ extend করেন।

Traditional Approach (CRUD)

• Same model read ও write দুটোতে — compromise।
• Normalized for write integrity = JOIN-heavy read = slow।
• Different scaling needs — same infrastructure।

CQRS Approach

• Separate models — different schema।
• Possibly separate databases।
• Sync via events।
• Read model optimized for query।

সুবিধা

• Independent scaling: Read-heavy app-এ read model আলাদা scale।
• Optimized models: Write normalized; read denormalized।
• Different storage: Write SQL, read Elasticsearch।
• Multiple read views: Same data, different projections।
• Flexibility: Read model evolve write-কে ভাঙা ছাড়া।
• Performance: Read query super-fast।
• Security: Read-only access naturally।

Challenges

Eventual Consistency

Write hয়ার পর read model update হতে সময় লাগে — user-এর কাছে stale data।

Complexity

Two model maintain — code, deployment double।

Sync Mechanism

Write → read sync কীভাবে? Event-driven typical।

Operational Overhead

Two DB infrastructure।

CQRS + Event Sourcing

প্রায়শই pair করা হয়:

• Write side: events store।
• Read side: events থেকে projection বানিয়ে denormalized data।
• Multiple read model — same event source।

উদাহরণ — E-commerce Product

Write side

• Normalized: products, categories, prices, inventory আলাদা table।
• ACID transaction।
• Admin update easy।

Read side (multiple)

• Product detail page: Denormalized doc with all info।
• Search: Elasticsearch — full-text indexed।
• Recommendations: Graph DB — user-product relationships।
• Analytics: Pre-aggregated sales data।

কখন CQRS?

• Read-write ratio highly skewed (১০০:১+)।
• Different query patterns।
• Complex business logic।
• Multiple read view — search, analytics, etc।
• Event-sourced system।
• Independent team-এর read/write evolve।

কখন CQRS না?

• Simple CRUD app।
• Read-write balanced।
• Strong consistency mandatory।
• Small team — overhead সইতে কষ্ট।

CQRS Variations

Light CQRS

Same DB, separate models in code। Sync কম।

Full CQRS

Separate DB, async sync, event-driven।

CQRS without Event Sourcing

Write DB থেকে CDC (Change Data Capture) দিয়ে read DB sync।

বাস্তব উদাহরণ

• E-commerce: Product write SQL, search Elasticsearch।
• Banking: Transaction events; multiple reports/dashboard projections।
• Social media: Post create event-driven; timeline feed Redis read model।
• Booking: Reservation strict ACID; availability search dimensional read model।

সাধারণ ভুল ধারণা

1. "CQRS = Event Sourcing": না — CQRS without ES সম্ভব।
2. "CQRS overhead always worth": Simple app-এ overkill।
3. "Two DB always": Light CQRS-এ same DB possible।
4. "Strong consistency পাওয়া যায়": Eventual consistency স্বাভাবিক।

Best Practices

• Bounded context level-এ apply, full system নয়।
• Eventual consistency UI-তে handle (loading, syncing indicator)।
• Event-driven sync — Kafka, CDC।
• Read model-এ idempotent updates।
• Monitor sync lag।
• Don't start with CQRS — refactor-এ যান।