Wstęp
Dyskutując o rozwoju aplikacji fintech, zespoły często kierują się architekturą jako jedyną podstawą wyboru technicznego, pomijając inne czynniki. W rzeczywistości jednak wszystkie te decyzje architektoniczne opierają się przede wszystkim na decyzjach biznesowych. Wybrana architektura wpływa na szybkość uruchomienia aplikacji, łatwość jej rozwoju w czasie, koszty długoterminowego wsparcia i utrzymania platformy oraz gotowość do audytów, kontroli zgodności i przeglądów ryzyka operacyjnego. Dla założycieli i kadry zarządzającej ostateczny wybór architektury ma znacznie większe znaczenie niż jej nowoczesność, ze względu na wpływ, jaki wywiera na sukces firmy.
Z naszego doświadczenia w Appricotsoft wynika, że zespoły albo komplikowały swoje wybory na wczesnym etapie, albo zbyt długo pozostawały zbyt uproszczone, co nie przynosiło korzyści produktowi końcowemu. Celem wyboru architektury nie jest znalezienie najmodniejszego rozwiązania, lecz architektury, która jest zgodna z etapem rozwoju produktu, poziomem doświadczenia zespołu, poziomem presji regulacyjnej i planem działania.
Zgodność architektury z tymi czynnikami jest niezwykle ważna w obszarze FinTech, ponieważ zbyt często aplikacja FinTech funkcjonuje w szerszym ekosystemie strategicznym niż tylko jako aplikacja. Zazwyczaj aplikacja FinTech znajduje się w szerszej perspektywie, obejmującej weryfikację tożsamości, aplikacje płatnicze, integrację z dostawcami bankowymi, uzgadnianie, procesy obsługi klienta, środki zapobiegające oszustwom, wymogi raportowania i środki bezpieczeństwa. Dokonywanie niewłaściwych wyborów architektonicznych generuje nie tylko dług techniczny; podejmowanie niewłaściwych decyzji architektonicznych stwarza ryzyko związane z dostawą.
Dlatego traktujemy architekturę jako część strategii produktu. Musi ona wspierać szybką iterację, ale musi też chronić zaufanie. A w fintech zaufanie jest najważniejsze.
Dlaczego architektura Fintech ma znaczenie
Jest wiele branż, w których problem można rozwiązać później… w przypadku FinTech zapłacisz wysoką cenę, jeśli tak zrobisz.
Jeśli płatność się opóźni, dojdzie do podwójnej transakcji, saldo będzie niespójne, nie będzie możliwości łatwego sprawdzenia transakcji lub nie będziesz dobrze radzić sobie z ponawianiem transakcji, wszystko to wpłynie na to, jak użytkownicy Cię postrzegają i jak jesteś postrzegany w kontekście zgodności z zasadami.
Jeśli Twój system nie rozumie dokładnie, co się stało, kiedy to się stało i z jakich powodów, spowodujesz problemy swojemu zespołowi operacyjnemu, zespołowi obsługi klienta i w konsekwencji swoim użytkownikom.
Dlatego dobra firma zajmująca się tworzeniem oprogramowania FinTech nie powinna zaczynać od dyskusji na temat takich haseł jak “monolit kontra mikrousługi”. Zamiast tego powinni zacząć od takich pytań jak:
- Jakie są najbardziej wrażliwe procesy robocze w tym produkcie?
- Co należy monitorować pod kątem zgodności i wsparcia?
- Gdzie znajdują się potencjalne punkty awarii?
- Gdzie muszę mieć szybki czas reakcji i gdzie muszę zachować kontrolę?
- Co zespół może rozsądnie i skutecznie realizować 6 miesięcy po starcie?
Gdy firma zajmująca się tworzeniem oprogramowania FinTech staje przed tego typu pytaniami i odpowiedziami, zazwyczaj kończy z architekturą znacznie lepszą niż ta, która po prostu próbuje odtworzyć architekturę dużego banku lub dużej firmy zajmującej się płatnościami.
Opcja 1: Monolit
Monolit to pojedyncza aplikacja, która zawiera większość funkcjonalności firmy, wszystkie w ramach jednej bazy kodu i jest wdrażana wspólnie. Chociaż koncepcja wykorzystania architektury monolitycznej może wydawać się przestarzała, wciąż jest to realna opcja dla wielu współczesnych produktów fintech na wczesnym etapie rozwoju.
Dzięki dobrze ustrukturyzowanej architekturze monolitycznej, Twój zespół programistów będzie mógł szybko uruchomić swój pierwszy produkt, ponieważ praca z systemem monolitycznym będzie wymagała mniejszej liczby ruchomych części. Aby szybko dostarczać kod, możesz go lokalnie refaktoryzować, testować lokalnie, łatwo wdrażać i minimalizować narzut operacyjny. Jeśli nadal pracujesz nad walidacją procesu wdrażania, procedur KYC, ścieżek płatności lub logiki portfela, prostota architektury da Ci przewagę.
W przypadku produktu MVP monolit często ma sens, gdy:
- Zespół jest mały,
- Mapa drogowa wciąż się zmienia,
- Produkt znajduje dopasowanie produktu do rynku,
- Wolumen transakcji jest możliwy do opanowania,
- a firma musi działać ostrożnie, nie tworząc niepotrzebnej złożoności infrastruktury.
Największym błędem dotyczącym architektury monolitycznej jest przekonanie, że automatycznie oznacza ona bałagan w systemie. Architektura monolityczna może być dobrze ustrukturyzowana, modułowa, przetestowana i gotowa do produkcji, jeśli jest budowana z wykorzystaniem zdefiniowanych domen.
Wiele startupów fintechowych rozpoczyna działalność od modułowej architektury monolitycznej. Oznacza to po prostu, że masz jedną, możliwą do wdrożenia aplikację, ale modułowo obsługujesz różne obszary, takie jak użytkownicy, onboarding, KYC, płatności, rejestry, powiadomienia i narzędzia administracyjne. Daje to szybkość architektury monolitycznej, ale jednocześnie możliwość płynniejszego przejścia na architekturę opartą na mikrousługach, jeśli zajdzie taka potrzeba.
Wadą jest to, że wraz z rozwojem firmy, skalowanie monolitu może być trudniejsze. Duże bazy kodu zwiększają sprzężenie. Wydania stają się bardziej ryzykowne. Zespoły wzajemnie sobie przeszkadzają. A jeśli jedna domena nagle będzie miała zupełnie inne potrzeby w zakresie skalowania lub bezpieczeństwa, model pojedynczej aplikacji może zacząć Cię spowalniać.
Jednak dla wielu założycieli lepszym pytaniem nie jest “Czy monolit jest stary?” To jest “Czy modułowy monolit może zapewnić nam bezpieczną przyczepność?” Bardzo często odpowiedź brzmi: tak.
Opcja 2: Mikrousługi
Mikrousługi dzielą platformę na mniejsze części, umożliwiając korzystanie z wielu mniejszych usług, z których każda oferuje jedną funkcjonalność biznesową. W branży technologii finansowych może to obejmować oddzielne usługi uwierzytelniania, tworzenia profili klientów, KYC, przetwarzania płatności, zarządzania księgą rachunkową, powiadomień, raportowania, wykrywania oszustw lub integracji systemów.
Mikrousługi mają prawdziwy potencjał, gdy firma i produkt są gotowe na wdrożenie tego modelu.
Firmy zazwyczaj biorą pod uwagę mikrousługi, jeżeli:
- Różne sekcje ich platformy mają różne stawki zmian.
- Niektóre funkcje wymagają niezależnego skalowania.
- Zintegrowane zespoły muszą pracować niezależnie od siebie.
- Integracja staje się coraz trudniejsza do zarządzania.
- Występują problemy z koordynacją wdrożeń na całej platformie.
Załóżmy na przykład, że masz silnik transakcyjny, warstwę raportowania i system powiadomień, które mają różną wydajność lub cykle wydań; sensowne może być rozdzielenie tych systemów. Część rejestru odnosi się znacznie ściślej do wydania niż do powiadomienia marketingowego. Mikrousługi dają możliwość projektowania z uwzględnieniem tych realiów.
Jednak wdrożenie mikrousług zamiast usunąć złożoność systemu, zwiększy jego złożoność.
Zastępując wewnętrzne wywołania metod wywołaniami sieciowymi, dodałeś poziom złożoności. Przejście z zarządzania pojedynczym potokiem wdrażania do zarządzania wieloma zwiększa złożoność, którą musisz zarządzać. Przejście z zarządzania jednym zestawem logów do zarządzania obserwowalnością w rozproszonych usługach będzie wymagało znacznie więcej pracy niż poleganie wyłącznie na wbudowanej funkcjonalności aplikacji. Przejście z zarządzania pojedynczą granicą transakcji bazy danych do zarządzania spójnością między usługami zwiększy nakład pracy wymagany do zbudowania funkcjonalnej aplikacji.
Ten ostatni punkt jest punktem, w którym wiele zespołów fintechowych nie docenia kosztów.
W monolicie silna spójność jest łatwiejsza, ponieważ powiązane operacje często odbywają się w ramach jednej transakcji. W mikrousługach rozproszone transakcje są znacznie trudniejsze. Dlatego zespoły często polegają na wzorcach takich jak sagi lub przepływy pracy sterowane zdarzeniami, aby zachować spójność stanu w różnych usługach. Wskazówki dotyczące architektury firmy Microsoft opisuje wzorzec sagi konkretnie jako sposób zachowania spójności danych w różnych usługach w systemach rozproszonych.
Nie oznacza to, że mikrousługi są złym wyborem. Oznacza to, że trzeba na nie zapracować, a nie je zakładać.
Produkt z sześcioosobowym zespołem, jednym podstawowym przepływem transakcji i ewoluującym modelem biznesowym zazwyczaj nie potrzebuje dziesięciu usług. Skalowalny fintech z wieloma liniami produktów, dojrzałymi praktykami inżynieryjnymi, silnym zaangażowaniem DevOps i ścisłym podziałem domen często tego potrzebuje.
Opcja 3: Architektura sterowana zdarzeniami
Architektura oparta na zdarzeniach jest często wspominana w kontekście mikrousług, ale w rzeczywistości służy innemu celowi.
W architekturach sterowanych zdarzeniami części systemu reagują na zdarzenia biznesowe, takie jak rejestracja użytkownika, zatwierdzenie KYC, zainicjowanie płatności, rozliczenie wypłaty, zamrożenie karty lub podejrzenie oszustwa.
Zdarzenia pozwalają częściom systemu reagować asynchronicznie, zamiast uzależniać wszystkie procesy przepływu pracy wyłącznie od synchronicznych wywołań żądania/odpowiedzi. Jest to szczególnie korzystne w sektorze finansowym, gdzie wiele procesów biznesowych składa się z wielu etapów, jest silnie zintegrowanych i nie jest natychmiast dostępnych.
Na przykład przepływ płatności jest doskonałym przykładem tego, jak długo może trwać seria zdarzeń, zanim zostanie ukończona. Działanie użytkownika może wywołać uwierzytelnienie transakcji, wykrycie oszustwa, aktualizację rejestru, powiadomienia, działania uzgadniające i generowanie raportów. Nie ma potrzeby, aby wszystkie te procesy odbywały się w ramach jednego synchronicznego żądania. W rzeczywistości próba wymuszenia wykonania wszystkich czynności w ramach jednego żądania może zmniejszyć niezawodność całego systemu.
Architektura sterowana zdarzeniami oddziela komponenty i zwiększa odporność. Wymaga jednak również pewnej dyscypliny w projektowaniu, uwzględniając wyzwania operacyjne związane z przetwarzaniem asynchronicznym, takie jak ponawianie prób, duplikowanie kolejności, obserwowalność i ostateczna spójność.
Zespoły często borykają się z wyzwaniami operacyjnymi podczas korzystania z architektury sterowanej zdarzeniami. Cenią sobie elastyczność zdarzeń, ale nie biorą pod uwagę realiów operacyjnych podczas projektowania swoich rozwiązań.
Co wybierasz?
Proces Definiowania Rozwoju Fintech opiera się na wiedzy praktycznej, a nie ideologii. Odpowiedź na pytanie „Jak wybrać ramy” będzie miała charakter etapowy.
1. Monolityczny moduł (MVP/początkowa trakcja): Stopień złożoności i ilość pracy niezbędnej do stworzenia produktu zadecyduje o tym, czy zbudować modułowy monolit, czy też bardziej złożoną alternatywę polegającą na rozdzieleniu funkcji na osobne aplikacje.
Zalety: Stworzenie Twojego pierwszego produktu będzie szybsze, umożliwi sprawniejsze testowanie i audytowanie oraz będzie wiązało się z mniejszymi bieżącymi kosztami operacyjnymi.
2. Ekstrakcja usług (selektywna): Po zbudowaniu modułowego monolitu, wyodrębnij usługi, które umożliwią dalszy rozwój i separację tych usług (np. Ledger, Payment Orchestration itp.). Ważnym czynnikiem przy rozważaniu wyodrębnienia usługi jest ocena jej złożoności.
3. Zdarzeniowe, gdzie dodają wartości biznesowej: Korzystanie ze zdarzeń w celu obsługi przepływów pracy umożliwi Ci ich używanie jako mechanizmu rozdzielającego, zwiększy odporność Twoich produktów, umożliwi powtarzalność zdarzenia oraz umożliwi asynchroniczne przetwarzanie zdarzenia bez konieczności tworzenia modelu programowania opartego na zdarzeniach dla każdej funkcji Twojej aplikacji.
Podsumowując, rozpoczęcie od prostego MVP i przetworzenie go w środowisku testowym/audytowym zazwyczaj zapewni skuteczniejsze rozwiązanie niż rozpoczęcie od architektury opartej na usługach, po prostu dlatego, że brzmi to jak rozwiązanie architektury korporacyjnej.
Projektowanie interfejsów API w technologii finansowej: dlaczego prostota jest lepsza niż spryt
Projektowanie API jest istotne, ponieważ można je postrzegać jako system granic ryzyka. API definiują, kto może wykonywać poszczególne zadania w jakich warunkach, w jaki sposób będą weryfikowane, a także zapewniają ścieżkę audytu wykonanych działań.
Doskonały projekt interfejsu API musi koncentrować się na następujących koncepcjach:
- Kontrakty jawne;
- Przejrzyste wersjonowanie;
- Przewidywalna obsługa błędów;
- Silne uwierzytelnianie i autoryzacja;
- Idempotencja z ponownymi próbami; i
- Możliwość śledzenia żądań i przetwarzania w dół strumienia.
Założyciele firm zazwyczaj mierzą jedynie, czy API “działa”. Jednak doświadczone zespoły mierzą, czy API działa bezpiecznie, gdy jest odtwarzane w następujących warunkach:
- Ponawianie próby;
- Częściowe awarie;
- Przerwy;
- Niespójność na poziomie partnera (np. gdy Twój system opiera się na dostawcach zewnętrznych jako źródle KYC, otwartej bankowości, przetwarzania płatności, kontroli oszustw i powiadomień).
Warstwa API musi izolować złożoności zewnętrzne (pochodzące od stron trzecich) od emisji do reszty platformy.
Tworząc usługi rozwoju aplikacji mobilnych dla produktów Fintech, zalecamy, aby firma posiadała wewnętrzną logikę domeny, oddzieloną od komponentów publicznego/partnerskiego API. Oddzielenie logiki domeny od publicznych API wspiera wersjonowanie, kontrolę bezpieczeństwa i długoterminową strategię utrzymania.
Spójność danych: przejście do architektury fizycznej
To jest moment, w którym Twoja teoretyczna architektura staje się architekturą rzeczywistą.
W branży technologii finansowych spójność danych to coś więcej niż tylko element bazy danych. Obejmuje ona przepływy pieniężne, przejrzystość statusu, rozwiązywanie problemów, uzgadnianie, raportowanie i zaufanie klientów.
W architekturach monolitycznych osiągnięcie silnej spójności jest znacznie łatwiejsze, ponieważ w ramach tej samej transakcji można wykonywać wiele działań.
W przypadku stosowania mikrousług i systemów sterowanych zdarzeniami zazwyczaj konieczne jest zachowanie równowagi między wysoką spójnością a dostępnością, odpornością i oddzieleniem – co często przyczynia się do ostatecznego podejścia do spójności w części systemu.
Jest to dopuszczalne pod warunkiem, że jest to świadoma decyzja.
Użytkownicy końcowi są gotowi zaakceptować stan “przetwarzania” przez określony czas. Tolerują krótki okres, zanim otrzymają powiadomienie. Nie tolerują nieuzasadnionych rozbieżności salda, podwójnych opłat, opłat ani nieodwracalnych pomyłek.
Z tego powodu architektura fintech musi jasno określać:
- Które przepływy pracy wymagają silnej spójności.
- Które przepływy pracy mogą mieć ostateczną spójność.
- Które jest autorytatywnym źródłem prawdy dla każdej dziedziny.
- W jaki sposób będą śledzone zmiany stanów.
- W jaki sposób zespoły wsparcia będą w stanie zrozumieć, co się wydarzyło.
Na koniec należy zwrócić szczególną uwagę na konstrukcję rejestru. W wielu rozwiązaniach fintech rejestr (historia transakcji) staje się podstawą operacyjną rozwiązania i jako taki nie powinien być traktowany jako coś drugorzędnego.
Idempotentność: jedna z najważniejszych zasad projektowania fintech
Istotą idempotentności w branży technologii finansowych jest stworzenie ogólnego systemu, w którym bez względu na to, ile razy ponawiasz pojedyncze żądanie za pośrednictwem interfejsu API, otrzymasz ten sam wynik (bez dodatkowych rekordów), jeśli masz ten sam idempotentny klucz lub identyfikator.
Aby system jako całość był w pełni idempotentny, musisz mieć duże zaufanie do swoich umiejętności śledzenia wcześniej wysłanych żądań.
Można to zauważyć, jeśli weźmiemy pod uwagę, że ponawianie prób jest zjawiskiem powszechnym we wszystkich systemach, począwszy od sieci telefonii komórkowej, gdzie błąd może spowodować przekroczenie limitu czasu, a klienci mogą ponownie przesłać swoje żądania, aż po kolejki ponownie przetwarzające wiadomości z powodu awarii poprzedniego użytkownika, aż po wielokrotne klikanie przez ludzi.
Kiedy dokumentacja API Stripe odwołuje się do tej zasady, wyjaśnia, że gdy po raz pierwszy wysyłane jest żądanie z użyciem klucza idempotentności, wyniki wszelkich przyszłych prób z użyciem tego samego klucza idempotentności dadzą taki sam wynik.
Z praktycznego punktu widzenia, w zależności od rodzaju technologii wykorzystywanej przez zespół fintech, należy wziąć pod uwagę koncepcję idempotentności podczas tworzenia:
- płatności,
- wypłaty,
- transfery,
- obsługa webhooków,
- wywołania zwrotne zewnętrznego dostawcy i
- konsumenci wydarzeń.
Dojrzała architektura nie może po prostu zakładać, że “to się prawdopodobnie nie wydarzy”. Dojrzała architektura musi zakładać, że duplikaty będą istnieć i że będą powtarzane próby, i odpowiednio projektować.
Projektowanie zgodnie z wymogami regulacyjnymi od pierwszego dnia
Aby spełnić wymogi regulacyjne już od pierwszego dnia projektu, należy podjąć przemyślane podejście do architektury i projektu. Wymagania regulacyjne dotyczące produktu, takie jak KYC, PSD2, AML, dane płatnicze, audyty i reagowanie na incydenty, mogą kształtować architekturę i strukturę produktu od samego początku. Te wymogi regulacyjne mają szczególne znaczenie i znaczenie dla prac związanych z FinTech (PSD2, otwarta bankowość, KYC, integracja płatności, wykrywanie oszustw itp.).
Nie oznacza to nadmiernego projektowania. Chodzi o wczesne opracowanie odpowiednich elementów sterujących:
- przejrzyste ślady audytu,
- dostęp oparty na rolach,
- separacja środowiskowa,
- bezpieczne przetwarzanie tajemnic,
- niezmienne lub dobrze śledzone krytyczne zapisy,
- udokumentowane przepływy danych,
- i operacyjną widoczność wrażliwych przepływów pracy.
YMusisz wziąć pod uwagę realia, w jakich działają Twoje regulowane i wrażliwe procesy. Nie każda usługa powinna mieć dostęp do każdego rodzaju informacji lub danych (dobra architektura zapewni ograniczony zasięg).
W Appricotsoft wierzymy, że architektura musi zapewniać przewidywalność dostaw, widoczność ryzyka i jakość, które powinny być wbudowane w proces przepływu pracy, a nie dodawane do niego dopiero na końcu projektu. To podejście jest bezpośrednio zgodne z naszym Unison Framework: udostępnianie artefaktów projektu, cotygodniowe prezentacje, jasne ustalanie kompromisów, wykorzystanie sztucznej inteligencji do wsparcia realizacji, przy jednoczesnym zachowaniu odpowiedzialności za rezultaty przez poszczególnych pracowników.
Dostarczając rozwiązania w sektorze FinTech, niezwykle ważna jest dyscyplina w dostarczaniu rozwiązań, ponieważ decyzje dotyczące architektury nie są wyłącznie decyzjami technicznymi; mają one fundamentalny wpływ na zgodność, zaufanie do wydań i kontrolę biznesową.
Co zazwyczaj polecamy założycielom firm fintech
Ogólna zasada dla założycieli firm Fintech, którzy stworzyli nowy produkt Fintech lub po prostu chcą udoskonalić istniejący produkt Fintech, brzmi: wybierają “najprostszą” architekturę, która spełni wymogi i jednocześnie będzie obsługiwać produkt.
Dla większości firm Fintech oznacza to korzystanie z:
- Modułowy monolit
- Jasno określone granice domeny
- Silne kontrakty API
- Odpowiednie rejestrowanie audytów
- Idempotentne operacje krytyczne
- Selektywne wykorzystanie przetwarzania opartego na zdarzeniach w celu wspomagania.
Przechodź na mikrousługi tylko wtedy, gdy uważasz, że masz ku temu powody, a nie tylko pobożne życzenia. Projektując systemy, skup się na przejrzystości. Kolejny zespół, który będzie pracował nad Twoim produktem Fintech, musi być w stanie wyjaśnić, co się stało lub jak wszystko zostało zbudowane w przypadku incydentu; poradzić sobie z konsekwencjami podjętych decyzji; uzyskać akceptację dla Twoich produktów; zapewnić użytkownikom lepsze lub inne wsparcie; oraz móc kontynuować rozwój produktu, nie martwiąc się o ograniczenia wynikające z Twojej architektury.
W Appricotsoft lubimy tworzyć oprogramowanie, z którego jesteśmy dumni – praktyczne, przemyślane i uczciwe w kwestii kompromisów. Wpisuje się to w naszą szerszą wizję, że rozwój powinien być połączeniem jakości, odpowiedzialności, przejrzystości, a nie tylko aspiracji technicznych.
Jeśli rozważasz wprowadzenie na rynek nowego produktu Fintech lub przeprojektowanie istniejącego produktu Fintech, najlepsza architektura NIE musi być najbardziej skomplikowana. To architektura, która pozwoli Ci na pewne uruchomienie, przejrzystość działania i skalowanie bez utraty kontroli.
Sugerowane linki wewnętrzne do dodania w opublikowanym artykule
