QuickPay dla Trans.eu: mikroserwis do automatycznego finansowania zobowiązań finansowych
About the project
Trans.eu to jedna z największych giełd transportowych w Europie, łącząca dziesiątki tysięcy spedytorów i przewoźników. QuickPay to usługa działająca wewnątrz ekosystemu Trans.eu, umożliwiająca firmom transportowym szybkie finansowanie faktur, bez czekania na termin płatności od kontrahenta. Serwis pośredniczy w komunikacji z zewnętrznymi systemami faktoringowymi (m.in. TransCash) i automatyzuje cały proces: od weryfikacji wiarygodności kontrahenta, przez złożenie wniosku faktoringowego, po wygenerowanie dokumentów cesji wierzytelności.
Automatyczne finansowanie faktur dla użytkowników Trans.eu
Integracja z zewnętrznymi systemami faktoringowymi
Obsługa alternatywnych systemów finansowania
Automatyzacja generowania dokumentów cesji wierzytelności
From challenge
Key Challenges
Integracja z zewnętrznym systemem faktoringowym o niskiej dostępności
Integracja z zewnętrznym systemem faktoringowym o niskiej dostępności
Zewnętrzny system TransCash nie gwarantował wysokiej dostępności. W praktyce oznaczało to ryzyko, że dokumenty aplikacyjne, wnioski czy dane klientów mogły nie dotrzeć do systemu w czasie rzeczywistym. Każda utracona wiadomość to realne ryzyko finansowe dla użytkownika platformy. Konieczne było zbudowanie mechanizmu „watchdog", który śledzi status każdej operacji i gwarantuje jej ostateczne wykonanie, bez ingerencji użytkownika.
Niezawodna komunikacja między systemami finansowymi
Niezawodna komunikacja między systemami finansowymi
QuickPay musiał działać jako rzetelny pośrednik między Trans.eu a zewnętrznymi serwisami finansowymi, przekazując informacje o zmianach w firmach klientów do systemu windykacyjnego przez REST API, a odbierając zdarzenia za pośrednictwem brokera wiadomości. Każda niespójność danych między systemami mogła skutkować błędną oceną wiarygodności kontrahenta lub błędnie przetworzonym wnioskiem.
Złożoność architektury domenowej w środowisku produkcyjnym
Złożoność architektury domenowej w środowisku produkcyjnym
Obsługa finansowania faktur to proces wieloetapowy: weryfikacja kontrahenta, wycena, złożenie wniosku, generowanie dokumentów cesji, potwierdzenie. Każdy etap musi być odporny na awarie i obsługiwać scenariusze częściowego wykonania. Architektura oparta na DDD i CQRS wymagała precyzyjnego podziału odpowiedzialności na każdym etapie implementacji.
Zapewnienie obserwowalności i jakości w systemie finansowym
Zapewnienie obserwowalności i jakości w systemie finansowym
Serwis obsługiwał procesy finansowe, gdzie błąd lub brak potwierdzenia operacji był bezpośrednio odczuwalny przez klientów biznesowych. Konieczne było wdrożenie pełnego monitoringu (Grafana, Kibana, Consul), systemu testów (jednostkowych, integracyjnych, pact testów), a także automatycznego generowania i wersjonowania dokumentacji API (OpenAPI, AsyncAPI) bezpośrednio w repozytorium kodu.
Kluczowe wymagania funkcjonalne i niefunkcjonalne
Funkcjonalne
- API do obsługi i zarządzania wnioskami finansowymi użytkowników
- Weryfikacja wiarygodności kontrahentów przez systemy faktoringowe
- Automatyczne generowanie dokumentów cesji wierzytelności
- Powiadamianie systemu windykacyjnego o zmianach w firmach klientów przez REST API
- System reprocessingu - ponowne przetwarzanie poleceń, które nie zostały wykonane
- Obsługa alternatywnych systemów finansowania: QuickPay, Bonabanco, SafePay
- Frontend umożliwiający użytkownikom składanie wniosków i śledzenie statusu finansowania
Niefunkcjonalne
- Odporność na niską dostępność zewnętrznych systemów faktoringowych
- Monitorowanie wydajności i zdrowia systemu (Grafana, Kibana, Consul)
- Automatyczna dokumentacja API generowana i przechowywana w repozytorium GIT
- Pełne pokrycie testami: jednostkowymi, integracyjnymi, pact testami (PactBroker)
- Infrastruktura na AWS (S3, RDS, ECS) - konteneryzacja i skalowalność
- Migracje schematu bazy danych zarządzane przez Liquibase
Through the solution
Through the solution
Architektura mikroserwisowa oparta na DDD i CQRS
fireup.pro dostarczyło zespół, który zaprojektował i wdrożył QuickPay jako samodzielny mikroserwis w architekturze domenowej. Rdzeń systemu zbudowany w Java ze Spring Boot odpowiadał za cały cykl życia wniosku faktoringowego.
Backend (Java/Spring Boot)
Zaprojektowanie architektury i podział domenowy (DDD)- wyraźne granice między weryfikacją kontrahentów, obsługą wniosków, generowaniem dokumentów i komunikacją zewnętrzną. Implementacja wzorca CQRS separującego operacje zapisu i odczytu. Integracja z RabbitMQ jako brokera wiadomości. QuickPay subskrybował zdarzenia o zmianach w firmach klientów i publikował powiadomienia do systemu windykacyjnego. System reprocessingu obsługujący polecenia, które nie powiodły się przy pierwszej próbie, z logiką ponowień i alertowaniem. Migracje schematu baz danych zarządzane przez Liquibase, ORM przez Hibernate, baza MariaDB.
Infrastruktura i obserwowalność
Wdrożenie na AWS z wykorzystaniem ECR (rejestr kontenerów), ECS (orkiestracja) i S3 (przechowywanie dokumentów). Monitoring aplikacji i zdrowia systemu w Grafana, Kibana i Consul. Pełen zestaw testów: jednostkowe, integracyjne i pact testy weryfikujące kontrakty między serwisami (PactBroker). Mechanizm automatycznego generowania dokumentacji OpenAPI i AsyncAPI z zapisem wersji w repozytorium GIT.
Frontend
Interfejs użytkownika zbudowany w React.js z TypeScript umożliwiał składanie wniosków o finansowanie, śledzenie statusu i przeglądanie historii operacji.
QA i automatyzacja testów
Testy automatyczne oparte na Selenium weryfikujące przepływy użytkownika end-to-end.
Metodyka pracy
Zespół pracował w bliskiej integracji z wewnętrznym zespołem Trans.eu. Każdy PR przechodził code review z naciskiem na poprawność domenową i odporność na awarie, szczególnie istotne w kontekście operacji finansowych. Architektura była projektowana iteracyjnie, z przemyślanym podziałem odpowiedzialności między moduły.
To the success
Technological outcomes
Mikroserwis wdrożony na produkcję
QuickPay został zintegrowany z ekosystemem Trans.eu i udostępniony użytkownikom platformy. Funkcje micro-faktoringu działają produkcyjnie, obsługując realne wnioski finansowe przewoźników i spedytorów.
Niezawodna integracja z TransCash
Mechanizm watchdog i system reprocessingu wyeliminował ryzyko utraty operacji przy niskiej dostępności zewnętrznego systemu faktoringowego. Każde polecenie jest śledzone do momentu ostatecznego potwierdzenia.
Pełna obserwowalność systemu finansowego
Monitoring w Grafana, Kibana i Consul daje pełny wgląd w wydajność i stan systemu. Błędy są wykrywane aktywnie, nie przez zgłoszenia użytkowników.
Dokumentacja API jako kod
Automatycznie generowana dokumentacja OpenAPI i AsyncAPI jest wersjonowana w repozytorium, każda zmiana kontraktu jest utrwalona i śledzona.
Project team
Robert Pietrzyński
Senior Backend Developer
Tech stack
Java
Spring boot
Amazon S3
Amazon ECR
Amazon ECS
Maria DB
HIBERNATE
RabbitMQ
Liquibase
Your success is our success
See how we can build a technological advantage for your company together.
We have a team that truly knows its stuff — we'll help you find a solution that works.
Conclusions & recommendations
W systemach finansowych niezawodność ważniejsza niż szybkość.
Zewnętrzny system faktoringowy dostępny w 80% to za mało, gdy brak potwierdzenia operacji oznacza realną stratę finansową dla klienta. Mechanizm watchdog i system reprocessingu to nie opcja, lecz wymóg projektowy dla każdej integracji z systemem zewnętrznym przetwarzającym pieniądze.
DDD i CQRS opłacają się w domenach o wysokiej złożoności.
Proces faktoringowy to wiele stanów, aktorów i reguł biznesowych. Architektura domenowa z wyraźnymi granicami kontekstów pozwoliła na bezpieczną iterację i rozszerzanie funkcjonalności bez rosnącego chaosu w kodzie.
Dokumentacja API jako artefakt, nie dodatek.
Automatyczne generowanie OpenAPI i AsyncAPI z zapisem w GIT sprawiło, że kontrakty między serwisami były zawsze aktualne i weryfikowalne przed wdrożeniem. W środowisku mikroserwisowym to podstawa bezpiecznego rozwoju.
Monitoring finansowy wymaga aktywnego podejścia.
Cicha awaria (polecenie, które nie rzuca wyjątku, ale nie dociera do celu) jest groźniejsza niż jawny błąd. Grafana, Kibana i Consul dały zespołowi aktywny wgląd w stan systemu, zamiast czekania na zgłoszenia klientów.
