داده‌ی اختصاصی هر سرویس (Database per Service)

یک اصل بنیادی: هیچ پایگاه‌داده‌ی مشترکی نباشد

یکی از مهم‌ترین و سخت‌گیرانه‌ترین اصول در معماری میکروسرویس این است که هر سرویس باید پایگاه‌داده‌ی مخصوص به خود را داشته باشد و هیچ سرویس دیگری نباید مستقیماً به آن پایگاه‌داده دسترسی داشته باشد. تنها راه دسترسی به داده‌ی یک سرویس، از طریق API آن سرویس است.

این اصل شاید در نگاه اول ناکارآمد به نظر برسد (چرا داده تکراری شود؟) اما دلیل آن حیاتی است: اگر دو سرویس یک پایگاه‌داده‌ی مشترک داشته باشند، تغییر ساختار جدول توسط یک تیم می‌تواند بی‌اطلاع تیم دیگر را بشکند و عملاً استقلال دیپلوی که هدف اصلی میکروسرویس است از بین می‌رود. پایگاه‌داده‌ی مشترک، محبوب‌ترین ضدالگو (anti-pattern) در پروژه‌های میکروسرویس ناموفق است.

پیامد: داده‌ی تکراری و سازگاری نهایی

پذیرش این اصل به این معناست که گاهی داده باید بین سرویس‌ها تکرار (duplicate) شود. مثلاً سرویس سفارش برای نمایش نام محصول، نیازی نیست هر بار از سرویس کاتالوگ سؤال کند؛ می‌تواند یک کپی سبک از نام و قیمت را در زمان ثبت سفارش نگه دارد. این رویکرد به قیمت پذیرفتن سازگاری نهایی (Eventual Consistency) به‌جای سازگاری فوری تمام می‌شود؛ یعنی ممکن است برای مدت کوتاهی، داده‌ی تکراری در دو سرویس کمی متفاوت باشد تا رویدادهای به‌روزرسانی به همه‌جا برسند. همگام نگه‌داشتن این داده‌های تکراری معمولاً از طریق پیام‌رسانی ناهمگام انجام می‌شود که در فصل بعد بررسی می‌کنیم.