Saya yakin Anda melihat ini datang, "Tergantung".
Itu tergantung pada segalanya. Dan solusi untuk berbagi data Pelanggan untuk departemen A mungkin sangat berbeda untuk berbagi data Pelanggan dengan departemen B.
Konsep favorit saya yang telah meningkat selama bertahun-tahun adalah konsep "Konsistensi Akhir". Istilah ini berasal dari Amazon yang berbicara tentang sistem terdistribusi.
Premisnya adalah bahwa sementara keadaan data di seluruh perusahaan terdistribusi sekarang mungkin tidak sepenuhnya konsisten, "pada akhirnya" akan demikian.
Misalnya, ketika catatan pelanggan diperbarui pada sistem A, data pelanggan sistem B sekarang basi dan tidak cocok. Tapi, "akhirnya", record dari A akan dikirim ke B melalui beberapa proses. Jadi, pada akhirnya, kedua instance akan cocok.
Saat Anda bekerja dengan satu sistem, Anda tidak memiliki "EC", melainkan Anda memiliki pembaruan instan, satu "sumber kebenaran", dan, biasanya, mekanisme penguncian untuk menangani kondisi balapan dan konflik.
Semakin mampu operasi Anda bekerja dengan data "EC", semakin mudah untuk memisahkan sistem ini. Contoh sederhananya adalah Data Warehouse yang digunakan oleh sales. Mereka menggunakan DW untuk menjalankan laporan harian mereka, tetapi mereka tidak menjalankan laporan mereka sampai pagi hari, dan mereka selalu melihat data "kemarin" (atau sebelumnya). Jadi tidak perlu waktu nyata agar DW benar-benar konsisten dengan sistem operasi harian. Sangat dapat diterima untuk sebuah proses berjalan pada, katakanlah, tutup bisnis dan bergerak selama hari-hari transaksi dan aktivitas secara massal dalam operasi pembaruan tunggal yang besar.
Anda dapat melihat bagaimana persyaratan ini dapat menyelesaikan banyak masalah. Tidak ada perselisihan untuk data transaksional, jangan khawatir bahwa beberapa data laporan akan berubah di tengah akumulasi statistik karena laporan membuat dua kueri terpisah ke database langsung. Tidak perlu untuk obrolan detail tinggi untuk menyedot jaringan dan pemrosesan cpu, dll. di siang hari.
Nah, itu contoh EC yang ekstrim, disederhanakan, dan sangat kasar.
Tetapi pertimbangkan sistem besar seperti Google. Sebagai konsumen Penelusuran, kami tidak tahu kapan atau berapa lama waktu yang dibutuhkan untuk hasil penelusuran yang Google panen hingga bagaimana di laman penelusuran. 1 ms? 1s? 10 detik? 10 jam? Sangat mudah untuk membayangkan bagaimana jika Anda menekan server Pantai Barat Google, Anda mungkin mendapatkan hasil pencarian yang berbeda daripada jika Anda menekan server Pantai Timur mereka. Kedua contoh ini sama sekali tidak konsisten. Tetapi secara besar-besaran, mereka sebagian besar konsisten. Dan untuk kasus penggunaannya, konsumen mereka tidak terlalu terpengaruh oleh kelambatan dan penundaan.
Pertimbangkan email. A ingin mengirim pesan ke B, tetapi dalam prosesnya pesan dirutekan melalui sistem C, D, dan E. Setiap sistem menerima pesan, memikul tanggung jawab penuh untuk itu, dan kemudian menyerahkannya ke yang lain. Pengirim melihat email sedang dalam perjalanan. Penerima tidak benar-benar melewatkannya karena mereka belum tentu tahu kedatangannya. Jadi, ada jendela besar waktu yang diperlukan untuk pesan tersebut untuk bergerak melalui sistem tanpa ada yang peduli mengetahui atau peduli tentang seberapa cepat itu.
Di sisi lain, A bisa saja sedang menelepon dengan B. "Saya baru saja mengirimnya, apakah Anda sudah mendapatkannya? Sekarang? Sekarang? Dapatkan sekarang?"
Jadi, ada semacam tingkat kinerja dan respons yang mendasari dan tersirat. Pada akhirnya, "akhirnya", kotak keluar A cocok dengan kotak masuk B.
Penundaan ini, penerimaan data basi, apakah itu berumur satu hari atau 1-5 detik, adalah yang mengontrol kopling utama sistem Anda. Semakin longgar persyaratan ini, semakin longgar koplingnya, dan semakin banyak fleksibilitas yang Anda miliki dalam hal desain.
Ini berlaku sampai ke inti di CPU Anda. Aplikasi modern, multi inti, multi-utas yang berjalan pada sistem yang sama, dapat memiliki pandangan berbeda dari data "sama", hanya mikrodetik yang ketinggalan zaman. Jika kode Anda dapat bekerja dengan benar dengan data yang berpotensi tidak konsisten satu sama lain, maka selamat hari, itu akan berjalan lancar. Jika tidak, Anda perlu memberikan perhatian khusus untuk memastikan data Anda benar-benar konsisten, menggunakan teknik seperti kualifikasi memori yang mudah menguap, atau konstruksi penguncian, dll. Semuanya, dengan caranya sendiri, memerlukan biaya.
Jadi, ini adalah dasar pertimbangan. Semua keputusan lain dimulai dari sini. Menjawab ini dapat memberi tahu Anda cara mempartisi aplikasi di seluruh mesin, sumber daya apa yang dibagikan, dan bagaimana mereka dibagikan. Protokol dan teknik apa yang tersedia untuk memindahkan data, dan berapa biaya yang dibutuhkan dalam hal pemrosesan untuk melakukan transfer tersebut. Replikasi, load balancing, pembagian data, dll. Semua berdasarkan konsep ini.
Edit, sebagai tanggapan atas komentar pertama.
Benar, persis. Permainan di sini, misalnya, jika B tidak bisa mengubah data pelanggan, lalu apa salahnya mengubah data pelanggan? Bisakah Anda "mengambil risiko" itu ketinggalan zaman untuk waktu yang singkat? Mungkin data pelanggan Anda masuk cukup lambat sehingga Anda dapat langsung mereplikasinya dari A ke B. Katakanlah perubahan dimasukkan ke dalam antrian yang, karena volume rendah, dapat diambil dengan mudah (<1s), tetapi bahkan itu akan "keluar dari transaksi" dengan perubahan asli, dan ada jendela kecil di mana A akan memiliki data yang B tidak.
Sekarang pikiran benar-benar mulai berputar. Apa yang terjadi selama 1 detik "lag", apa skenario terburuk yang mungkin terjadi. Dan dapatkah Anda merekayasa di sekitarnya? Jika Anda dapat merekayasa sekitar lag 1 detik, Anda mungkin dapat merekayasa sekitar lag 5 detik, 1 m, atau bahkan lebih lama. Berapa banyak data pelanggan yang sebenarnya Anda gunakan di B? Mungkin B adalah sistem yang dirancang untuk memfasilitasi pengambilan pesanan dari inventaris. Sulit membayangkan sesuatu yang lebih penting daripada sekadar ID Pelanggan dan mungkin nama. Hanya sesuatu untuk mengidentifikasi siapa pesanan itu saat sedang dirakit.
Sistem pengambilan tidak perlu mencetak semua informasi pelanggan hingga akhir proses pengambilan, dan pada saat itu pesanan mungkin telah berpindah ke sistem lain yang mungkin lebih mutakhir dengan, terutama, informasi pengiriman, jadi pada akhirnya sistem pengambilan hampir tidak membutuhkan data pelanggan sama sekali. Bahkan, Anda dapat MENYEMBUHKAN dan mendenormalkan informasi pelanggan dalam urutan pengambilan, jadi tidak perlu atau mengharapkan sinkronisasi nanti. Selama ID Pelanggan benar (yang tidak akan pernah berubah) dan nama (yang sangat jarang berubah sehingga tidak layak untuk didiskusikan), itulah satu-satunya referensi nyata yang Anda butuhkan, dan semua slip pilihan Anda sangat akurat pada saat kreasi.
Triknya adalah pola pikir, memecah sistem dan berfokus pada data penting yang diperlukan untuk tugas tersebut. Data yang tidak Anda perlukan tidak perlu direplikasi atau disinkronkan. Orang-orang kesal pada hal-hal seperti denormalisasi dan reduksi data, terutama ketika mereka berasal dari dunia pemodelan data relasional. Dan dengan alasan yang baik, itu harus dipertimbangkan dengan hati-hati. Tetapi begitu Anda terdistribusi, Anda secara implisit telah didenormalisasi. Heck, Anda menyalinnya secara grosir sekarang. Jadi, sebaiknya Anda lebih pintar.
Semua ini dapat dikurangi melalui prosedur yang solid dan pemahaman yang menyeluruh tentang alur kerja. Identifikasi risiko dan buat kebijakan serta prosedur untuk menanganinya.
Namun bagian tersulitnya adalah memutuskan rantai ke DB pusat di awal, dan menginstruksikan orang-orang bahwa mereka tidak dapat "memiliki semuanya" seperti yang mereka harapkan jika Anda memiliki satu penyimpanan informasi yang terpusat dan sempurna.
