Każdy z nas wie, że współdzielona baza danych to antypattern. Może to nie jest tak, że zawsze nie powinno się tak robić. Czasami jest to uzasadnione. Jednak taka decyzja musi być podjęta ŚWIADOMIE. A jak wiemy, z tą świadomością to różnie bywa… Przekonałem się o tym osobiście. Aby wyjaśnić problem, który napotkałem, posłużmy się przykładem.
Załóżmy, że mamy dwie aplikacje komunikujące się po HTTP. Oczywiście obok stoi jedna baza danych z jednym schematem, do której obydwie aplikacje są podłączone. Pierwsza z aplikacji jest sercem całości. To z nią komunikuje się UI i posiada ona wszystkie funkcjonalności wypracowane w firmie. Druga natomiast jest łącznikiem z innymi aplikacjami naszego klienta. Można więc ją nazwać oprogramowaniem pośredniczącym - middleware. Warto dodać, że obydwie aplikacje są rozwijane przez dwa niezależne zespoły.
Naszym zadaniem jest umożliwienie wgrania przez przeglądarkę pliku. Ma być on być przekazany aż do zewnętrznej aplikacji dostarczonej przez klienta. Jego droga będzie więc przebiegała tak jak na poniższym schemacie.
Na papierze wszystko wygląda super. Rzeczywistość jest jednak brutalna. Design został stworzony tak, że główna aplikacja zapisuje zawartość pliku na np. AWS S3 i metadane pliku w bazie danych. Następnie do aplikacji pomocniczej przekazuje identyfikator bazodanowy dla tego plik. I tutaj zaczyna się nieciekawa sytuacja, którą już przewnie przewidujesz. Podczas pobierania metadanych pliku z bazy danych w drugiej aplikacji dostajmy błąd. Taki rekord nie istnieje! Klient jest niezadowolony, a oczywiście dostało się nie temu zespołowi co powinno.
Transakcja w głównej aplikacji nie została zcommitowana przed wywołaniem pomocniczego serwisu. Stąd brak rekordu w bazie danych. Jasne, da się to łatwo naprawić. Jednak czy jest to design, w który warto brnąć dalej? Przykryjemy go szpachlą na potrzeby chwili, a w najmniej spodziewanym momencie przywita nas ponownie ze zdwojoną siłą. Może warto wziąć pod uwagę ten głośny sygnał i inaczej podejść do tematu?
Chciałem tym wpisem uczulić, że wszystko ma swoje dobre strony, które są neutralizowane przez minusy danego rozwiązania. Warto mieć to na uwadze podczas projektowania systemu. Jeśli natomiast dostajemy pierwsze sygnały na temat tego, że architektura została źle dobrana to trzeba się z niej jak najszybciej wycofać i wybrać inną. Oczywiście o ile nie jest za późno…