Part 2 · ডেটাবেস 📖 ১০ মিনিট পড়া 📝 ২০টি কুইজ

Database Federation

Function অনুযায়ী DB ভাগ — sharding-এর alternative।

📝 কুইজে যান

একটি e-commerce-এ user, product, order, payment — সব এক DB-তে। Database overwhelmed। Sharding জটিল। আরেকটি option: function অনুযায়ী আলাদা DB। User service-এর জন্য User DB, Order service-এর জন্য Order DB ইত্যাদি। এটাই Database Federation।

Database Federation কী?

Federation (functional partitioning) = এক monolithic DB-কে function/feature অনুযায়ী আলাদা DB-তে ভাগ করা। প্রতিটি federated DB একটি specific business domain handle করে।

উদাহরণ

Before federation:

[Single DB] - users (table) - products - orders - payments - forum_posts - analytics

After federation:

[User DB] [Product DB] [Order DB] [Forum DB] - users - products - orders - posts - profiles - inventory - payments - comments - sessions - reviews - shipping - threads

কেন Federation?

  • Performance: প্রতিটি DB ছোট, fast।
  • Independent scaling: Hot service-এর DB scale করুন।
  • Independent technology choice: User-এ MySQL, Forum-এ MongoDB।
  • Team autonomy: প্রতিটি team নিজের DB manage।
  • Failure isolation: Forum DB down = user/order unaffected।
  • Schema isolation: Different domain ভিন্ন schema evolve।

Federation vs Sharding

Sharding

  • Same table-এর row split
  • Same schema
  • Horizontal partition
  • Scale: data volume
  • Hash/range key দিয়ে

Federation

  • Different table-এ split
  • Different schema possible
  • Functional partition
  • Scale: feature load
  • Service boundary দিয়ে

একসাথে use করা যায় — federate first, তারপর hot DB shard।

Microservices-এর সাথে সম্পর্ক

Microservice আর্কিটেকচারে federation almost বাধ্যতামূলক — "Database per service" pattern:

  • প্রতিটি microservice-এর own DB।
  • Service-to-service communication API দিয়ে।
  • Cross-DB query restricted।

Challenges

Cross-DB JOIN

User profile + their orders একসাথে দরকার? দুই DB-তে আলাদা query।

  • সমাধান: Application-level join, denormalization, API gateway aggregation।

Distributed Transaction

Order create + payment debit + inventory deduct — different DB।

  • সমাধান: Saga pattern, eventual consistency।

Reporting

Cross-feature analytics কঠিন।

  • সমাধান: Data warehouse — সব DB থেকে ETL।

Data Duplication

User name product DB-এও দরকার (review-এ)। কোথায় keep?

  • সমাধান: Cache user data; eventual sync।

কখন Federation?

  • Application multiple distinct feature/domain।
  • Different feature-এ different scale need।
  • Different data model preferred (SQL vs NoSQL)।
  • Team autonomy চান।
  • Microservice migration plan।

কখন Federation না?

  • Small monolithic application।
  • Highly relational data — JOIN-heavy।
  • Strong cross-feature transaction প্রয়োজন।
  • Team small — operational overhead handle কঠিন।

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

  • Amazon: Order, inventory, recommendations — সব আলাদা DB।
  • Netflix: Polyglot persistence + per-service DB।
  • Uber: Trip, payment, user — federated, microservice।
  • Wikipedia: Wiki content, user, image — different DB।

Implementation Path

  1. Identify boundary: Domain-driven design, bounded context।
  2. Extract incrementally: এক feature, এক DB।
  3. Define API: Cross-domain access API দিয়ে — direct DB access বন্ধ।
  4. Data sync: Event-driven, eventual consistency।
  5. Reporting layer: Data warehouse বা CQRS।

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

  1. "Federation simple split": না — operational complexity।
  2. "Cross-DB JOIN possible easily": না — application/API level merge।
  3. "Federation = microservices": Related কিন্তু same নয় — federation DB-level, microservice service-level।

Best Practices

  • Bounded context define — domain-driven design।
  • API/Service boundary respect করুন — direct cross-DB query এড়ান।
  • Saga + eventual consistency।
  • Cache cross-domain data — duplicate accept করুন।
  • Reporting আলাদা layer (data warehouse, CDC)।
  • Incremental migration — big bang এড়ান।

📌 চ্যাপ্টার সারমর্ম

  • Federation = function/feature অনুযায়ী DB ভাগ।
  • Sharding row-based; Federation function-based।
  • Microservice "DB per service"-এর ভিত্তি।
  • Cross-DB JOIN, transaction — main challenge।
  • Saga + eventual consistency দিয়ে handle।