Jag är säker på att du såg detta komma, "Det beror på".
Det beror på allt. Och lösningen för att dela kunddata för avdelning A kan vara helt annorlunda för att dela kunddata med avdelning B.
Mitt favoritkoncept som har vuxit upp genom åren är konceptet "Eventual Consistency". Termen kom från att Amazon pratade om distribuerade system.
Utgångspunkten är att även om tillståndet för data över ett distribuerat företag kanske inte är helt konsekvent nu, så kommer det "så småningom" att bli det.
Till exempel, när en kundpost uppdateras på system A, är system B:s kunddata nu inaktuella och inte matchande. Men "så småningom" kommer posten från A att skickas till B genom någon process. Så till slut kommer de två instanserna att matcha.
När du arbetar med ett enda system har du inte "EC", snarare har du omedelbara uppdateringar, en enda "källa till sanning" och, vanligtvis, en låsmekanism för att hantera tävlingsförhållanden och konflikter.
Ju bättre din verksamhet kan arbeta med "EC"-data, desto lättare är det att separera dessa system. Ett enkelt exempel är ett Data Warehouse som används av försäljning. De använder DW för att köra sina dagliga rapporter, men de kör inte sina rapporter förrän tidigt på morgonen, och de tittar alltid på data från "igår" (eller tidigare). Så det finns inget realtidsbehov för att DW ska vara helt överensstämmande med det dagliga driftsystemet. Det är helt acceptabelt att en process körs vid, till exempel, när verksamheten är stängd och flyttar över dagarnas transaktioner och aktiviteter i en stor, enda uppdateringsoperation.
Du kan se hur detta krav kan lösa många problem. Det finns inget argument för transaktionsdata, ingen oro för att vissa rapportdata kommer att ändras mitt under ackumuleringen av statistiken eftersom rapporten gjorde två separata frågor till livedatabasen. Inget behov av att prat med hög detaljrikedom suger upp nätverks- och CPU-bearbetning etc. under dagen.
Nu, det är ett extremt, förenklat och väldigt grovt exempel på EM.
Men överväg ett stort system som Google. Som konsument av Sök har vi ingen aning om när eller hur lång tid det tar för ett sökresultat som Google skördar till hur uppe på en söksida. 1 ms? 1s? 10-tal? 10 timmar? Det är lätt att föreställa sig hur om du träffar Googles västkustservrar kan du mycket väl få ett annat sökresultat än om du träffar deras östkustservrar. På ingen punkt är dessa två fall helt konsekventa. Men i stort sett är de mest konsekventa. Och för deras användningsfall påverkas deras konsumenter inte riktigt av fördröjningen och förseningen.
Överväg e-post. A vill skicka meddelande till B, men i processen dirigeras meddelandet genom system C, D och E. Varje system accepterar meddelandet, tar det fullständiga ansvaret för det och lämnar sedan över det till ett annat. Avsändaren ser e-postmeddelandet gå på väg. Mottagaren saknar det egentligen inte eftersom de inte nödvändigtvis vet att det kommer. Så det finns ett stort tidsfönster som det kan ta för meddelandet att flytta genom systemet utan att någon berörd vet eller bryr sig om hur snabbt det är.
Å andra sidan kunde A ha varit i telefon med B. "Jag har precis skickat det, har du fått det ännu? Nu? Nu? Få det nu?"
Det finns alltså någon form av underliggande, underförstådd nivå av prestanda och respons. I slutändan, "så småningom", matchar A:s utkorg B inkorg.
Dessa förseningar, acceptansen av inaktuella data, oavsett om de är en dag gamla eller 1-5 s gamla, är det som styr den ultimata kopplingen av dina system. Ju lösare detta krav är, desto lösare är kopplingen och desto mer flexibilitet har du till ditt förfogande när det gäller design.
Detta är sant ner till kärnorna i din CPU. Moderna, multi-core, multi-threaded applikationer som körs på samma system, kan ha olika vyer av "samma" data, bara mikrosekunder inaktuella. Om din kod kan fungera korrekt med data som potentiellt är inkonsekventa med varandra, happy day, den blir med. Om inte måste du ägna särskild uppmärksamhet åt att se till att dina data är helt konsekventa, genom att använda tekniker som flyktigt minne, eller låskonstruktioner, etc. Allt detta, på sitt sätt, kostar prestanda.
Så detta är grundövervägandet. Alla andra beslut börjar här. Genom att svara på detta kan du berätta hur du partitionerar applikationer mellan maskiner, vilka resurser som delas och hur de delas. Vilka protokoll och tekniker finns tillgängliga för att flytta data, och hur mycket det kommer att kosta i form av bearbetning att utföra överföringen. Replikering, lastbalansering, datadelning, etc. etc. Allt baserat på detta koncept.
Redigera, som svar på första kommentaren.
Rätt, precis. Spelet här, till exempel, om B inte kan ändra kunddata, vad är då skadan med ändrad kunddata? Kan man "riska" att det är inaktuellt en kort tid? Kanske kommer din kunddata in så långsamt att du kan replikera den från A till B direkt. Säg att ändringen läggs i en kö som, på grund av låg volym, plockas upp lätt (<1s), men ändå skulle den vara "utan transaktion" med den ursprungliga ändringen, och så det finns ett litet fönster där A skulle ha data som B inte gör.
Nu börjar sinnet snurra på riktigt. Vad händer under dessa 1s av "lag", vad är det värsta möjliga scenariot. Och kan du ingenjör runt det? Om du kan konstruera runt en 1s fördröjning, kanske du kan konstruera runt en 5s, 1m eller ännu längre fördröjning. Hur mycket av kunddata använder du egentligen på B? Kanske är B ett system utformat för att underlätta orderplockning från lager. Svårt att föreställa sig att något mer är nödvändigt än bara ett kund-ID och kanske ett namn. Bara något för att grovt identifiera vem beställningen är för medan den håller på att monteras.
Plockningssystemet behöver inte nödvändigtvis skriva ut all kundinformation förrän i slutet av plockprocessen, och då kan beställningen ha gått vidare till ett annat system som kanske är mer aktuellt med, särskilt fraktinformation, så i slutändan behöver plocksystemet knappt någon kunddata alls. Faktum är att du kan bädda in och avnormalisera kundinformationen i plockordern, så det finns inget behov av eller förväntningar på att synkronisera senare. Så länge som kund-ID:t är korrekt (som aldrig kommer att ändras ändå) och namnet (som ändras så sällan att det inte är värt att diskutera), är det den enda riktiga referensen du behöver, och alla dina valkort är helt korrekta vid tidpunkten för skapande.
Tricket är tankesättet, att bryta upp systemen och fokusera på den väsentliga data som är nödvändig för uppgiften. Data du inte behöver behöver inte replikeras eller synkroniseras. Folk skaver på saker som denormalisering och datareduktion, särskilt när de kommer från den relationella datamodelleringsvärlden. Och med goda skäl bör det övervägas med försiktighet. Men när du väl blir distribuerad har du implicit denormaliserats. Heck, du kopierar det i grossistledet nu. Så du kan lika gärna vara smartare på det.
Allt detta kan mildras genom solida procedurer och grundlig förståelse för arbetsflödet. Identifiera riskerna och arbeta fram policy och rutiner för att hantera dem.
Men det svåra är att bryta kedjan till den centrala databasen i början och instruera folk att de inte kan "få allt" som de kan förvänta sig när du har en enda, central, perfekt informationsförråd.