hared-database-per-service Pola S

Dalam shared-database-per-service polanya, database yang sama dibagikan oleh beberapa layanan mikro. Anda perlu menilai arsitektur aplikasi dengan cermat sebelum mengadopsi pola ini, dan pastikan Anda menghindari hot table (tabel tunggal yang dibagi di antara beberapa layanan mikro). Semua perubahan database Anda juga harus kompatibel ke belakang; misalnya, pengembang dapat menjatuhkan kolom atau tabel hanya jika objek tidak direferensikan oleh versi saat ini dan sebelumnya dari semua layanan mikro.

Dalam ilustrasi berikut, database asuransi dibagi oleh semua layanan mikro dan kebijakan IAM menyediakan akses ke database. Ini menciptakan kopling waktu pengembangan; misalnya, perubahan dalam layanan mikro “Penjualan” perlu mengoordinasikan perubahan skema dengan layanan mikro “Pelanggan”. Pola ini tidak mengurangi dependensi antar tim pengembangan, dan memperkenalkan runtime coupling karena semua microservices berbagi database yang sama. Misalnya, transaksi “Penjualan” yang berjalan lama dapat mengunci tabel “Pelanggan” dan ini memblokir transaksi “Pelanggan”.

Anda harus mempertimbangkan untuk menggunakan pola ini jika:

• Anda tidak ingin terlalu banyak refactoring dari basis kode yang ada.

• Anda menegakkan konsistensi data dengan menggunakan transaksi yang memberikan atomisitas, konsistensi, isolasi, dan daya tahan (ACID).

• Anda ingin memelihara dan mengoperasikan hanya satu database.

• Menerapkan database-per-service pola ini sulit karena saling ketergantungan di antara layanan mikro Anda yang ada.

• Anda tidak ingin sepenuhnya mendesain ulang lapisan data yang ada.