Podsumowanie
Globalna firma z sektora FMCG, działająca w ponad 180 krajach, korzysta z platformy integrującej dane o produktach, promocjach i operacjach handlowych pomiędzy wieloma systemami.
Wraz ze wzrostem skali działalności system zaczął osiągać granice swojej wydajności – niektóre procesy synchronizacji danych trwały nawet 20 godzin. Jednocześnie platforma była krytyczna dla działalności firmy, dlatego jej całkowita przebudowa nie wchodziła w grę.
Zamiast tego wprowadzono serię precyzyjnych optymalizacji w istniejącej architekturze monolitycznej. Dzięki temu maksymalny czas przetwarzania workflow skrócił się z około 20 godzin do około 4 godzin, a codzienna synchronizacja danych została ustabilizowana.
Usprawnienia umożliwiły również rozszerzenie platformy na kolejne rynki oraz bardziej efektywne wykorzystanie infrastruktury chmurowej – bez konieczności wymiany systemu.
Klient
Naszym klientem jest globalna firma FMCG obecna na ponad 180 rynkach.
Organizacja zarządza złożonym środowiskiem operacyjnym obejmującym między innymi:
- rozbudowane portfolio produktów
- mechaniki promocji dostosowane do specyfiki poszczególnych rynków
- rozproszone struktury sprzedażowe
- wielopoziomową sieć partnerów i klientów
W takim modelu biznesowym ogromne znaczenie ma sprawna synchronizacja danych handlowych pomiędzy wieloma systemami i rynkami. Nawet niewielkie opóźnienia lub niespójności mogą wpływać na realizację promocji, operacje sprzedażowe czy stabilność procesów biznesowych.
Firma funkcjonuje również w środowisku korporacyjnym z jasno określonym nadzorem architektonicznym oraz formalnymi procesami zatwierdzania zmian technologicznych.
Wyzwanie
W momencie rozpoczęcia współpracy platforma integracji danych obsługiwała jeden rynek – Włochy.
System odpowiadał za agregowanie i synchronizację danych produktowych, promocyjnych oraz handlowych pomiędzy wieloma systemami wewnętrznymi.
Wydajność systemu
Niektóre procesy synchronizacji danych trwały nawet 20 godzin. Przy codziennych cyklach przetwarzania oznaczało to poważne ryzyko operacyjne:
- nakładanie się kolejnych cykli synchronizacji
- opóźnienia w aktualizacji danych w systemach
- ryzyko niespójności w mechanikach promocji
- zmniejszony margines bezpieczeństwa operacyjnego
Ograniczenia architektury
System funkcjonował jako duży monolit, co oznaczało między innymi:
- w pełni synchroniczne przetwarzanie
- brak równoległego wykonywania operacji
- przetwarzanie dużych zbiorów danych w pamięci
Migracja do architektury mikroserwisowej byłaby technicznie bardziej elegancka, jednak nie była możliwa ze względu na krytyczność systemu dla działalności biznesowej oraz brak tolerancji na przestoje.
Rosnące koszty infrastruktury
Duże zużycie zasobów infrastruktury – szczególnie pamięci RAM i mocy obliczeniowej – powodowało:
- konieczność kosztownego skalowania pionowego
- ograniczoną elastyczność infrastruktury
- zwiększone ryzyko niestabilności przy rosnących wolumenach danych
Ekspansja na kolejne rynki
Firma planowała rozszerzyć platformę na kolejne kraje. Każdy nowy rynek wprowadzał dodatkową złożoność, w tym:
- odmienne mechaniki promocji
- różnice w logice biznesowej
- różne modele obsługi produktów
- specyficzne zależności danych
Kluczowym wyzwaniem było więc zwiększenie skalowalności platformy bez przerywania jej działania i bez budowy nowego systemu od podstaw.
Rozwiązanie
Zamiast zastępować system nową architekturą, zdecydowano się na stopniową modernizację istniejącego monolitu.
Takie podejście pozwoliło:
- zachować ciągłość działania biznesu
- poprawić wydajność platformy
- przygotować system na dalszy wzrost skali
Efekty
Optymalizacja przetwarzania danych
Przebudowano logikę przetwarzania danych tak, aby:
- ograniczyć operacje na dużych zbiorach danych
- skrócić łańcuchy synchronicznych operacji
- zmniejszyć ilość danych przechowywanych w pamięci
Efekt: czas najdłuższego procesu skrócił się z około 20 godzin do około 4 godzin, co przywróciło bezpieczny margines dla codziennych cykli synchronizacji danych.
Lepsze wykorzystanie infrastruktury
- wprowadzono warstwy persystencji danych w chmurze
- dane ładowane są w mniejszych partiach
- znacząco ograniczono wykorzystanie pamięci RAM
Efekt: system działa stabilnie przy większych wolumenach danych, a zużycie infrastruktury zostało ograniczone.
Elastyczne skalowanie
Zamiast skalowania jednego dużego serwera wprowadzono:
- dynamiczne uruchamianie dodatkowych instancji obliczeniowych
- automatyczne wyłączanie zasobów po zakończeniu przetwarzania
Efekt: infrastruktura została dopasowana do rzeczywistego obciążenia, co poprawiło efektywność kosztową środowiska chmurowego.
Rozszerzenie platformy na nowe rynki
Po ustabilizowaniu wydajności systemu platforma została rozszerzona na kolejne kraje. Wprowadzono mechanizmy obsługujące specyficzną logikę biznesową poszczególnych rynków w ramach istniejącej architektury.
Efekt: organizacja mogła rozwijać platformę międzynarodowo bez budowy nowych systemów i bez przerywania działania istniejącego rozwiązania.
Co dalej?
W środowiskach enterprise problemy systemów rzadko wynikają wyłącznie z technologii. Często pojawiają się wtedy, gdy architektura nie nadąża za skalą działania biznesu.
Jeśli Twoja organizacja:
- rozwija duży system monolityczny pod presją wydajności
- mierzy się z rosnącymi kosztami infrastruktury chmurowej
- planuje ekspansję na nowe rynki z różnymi wymaganiami biznesowymi
warto zacząć od rozmowy technicznej o możliwych kierunkach optymalizacji i rozwoju architektury.
Porozmawiajmy.
