Velika Enterprise B2B Supply Chain & Logistics platforma bila je suočena sa ozbiljnim ograničenjima modernizacije zbog tesno povezanog Java Enterprise monolita vezanog za masivnu relacionu šemu baze podataka. Platforma je neprekidno radila pod produkcionim opterećenjem, dok su ugovorne finansijske penale činile planirane zastoje komercijalno neprihvatljivim. Forenzička analiza pokazala je da poslovni domeni nisu imali eksplicitno vlasništvo nad podacima i da su ostali povezani direktnim pristupom zajedničkom stanju baze. Raniji pokušaji dual-write pristupa na nivou aplikacije i polling baze uvodili su dodatne failure mode-ove, uključujući kontenciju baze, race condition-e, data drift, duplu obradu i kružne sinhronizacione petlje.
REŠENJE
SWARCS je redizajnirao strategiju modernizacije oko jednog autoritativnog write owner-a za svaki poslovni domen, Change Data Capture-a zasnovanog na transaction log-u umesto application polling-a i inkrementalne migracije saobraćaja korišćenjem Strangler Fig obrasca. Debezium je direktno iz transaction log-a hvatao commit-ovane promene i objavljivao ih kroz Apache Kafka event mesh. Novi servisi su konzumirali te promene i održavali sinhronizovano stanje dok je legacy platforma nastavila da obrađuje produkcioni saobraćaj. Kada bi domen bio spreman za izdvajanje, vlasništvo nad upisom prebacivano je kroz kontrolisanu migration barrier tačku i dinamičko API rutiranje.
KLJUČNI ARHITEKTONSKI POMAK
OD
poslovni domeni povezani kroz Java Enterprise monolit i zajedničko relaciono stanje, uz nejasno vlasništvo nad upisom i platform-wide zavisnosti tokom migracije
→
KA
eksplicitno vlasništvo nad podacima domena sa jednim autoritativnim write owner-om, transaction-log CDC-om, Kafka sinhronizacijom i inkrementalnom Strangler Fig migracijom
ZAKLJUČAK
Osmomesečni program modernizacije razdvojio je ključne poslovne funkcionalnosti dok je platforma nastavila da obrađuje produkcioni saobraćaj. Nije bilo planiranog downtime-a za migraciju, kontencija zaključavanja baze smanjena je za 40%, nije detektovan data drift, učestalost deployment-a promenjena je sa približno jednog izdanja na osam nedelja na dnevna nezavisna izdanja, a tokom migracije nisu zabeležena produkciona SLA kršenja.
ARHITEKTONSKA ANALIZA
KONTEKST I POSLOVNI UTICAJ
Platforma predstavlja Enterprise B2B Core Transaction & Supply Chain Logistics sistem koji upravlja kompletnim lancem operacija snabdevanja, obradom porudžbina, praćenjem zaliha i finansijskim poravnanjem kroz hiljade integrisanih enterprise partnera.
Platforma radi sa održivim protokom od približno 6.500 TPS, dok dnevni pikovi dostižu približno 12.000 TPS prema centralizovanoj relacionoj bazi podataka.
Sistem predstavlja poslovno kritičnu 24/7/365 platformu. Ugovorne obaveze podrazumevaju ozbiljne finansijske penale za prekide rada i neplanirane ili produžene prozore održavanja.
Nema planiranog gašenja platforme radi migracije
Nema praktične mogućnosti za produženi database write freeze
Visokorizični deployment ciklusi sa približno jednim izdanjem na osam nedelja uz koordinaciju više timova
Pojedinačne funkcionalnosti ne mogu se izdvojiti bez očuvanja legacy zavisnosti
Deployment ili migracioni incident može imati posledice na nivou cele platforme
Organizacija je praktično bila između dve neprihvatljive opcije: ostati na monolitu uz rastući tehnički dug, coupling i deployment rizik, ili sprovesti big-bang migraciju sa produženim downtime-om, složenim rollback-om, posledicama na nivou cele platforme i značajnim SLA i finansijskim rizikom.
OGRANIČENJE MODERNIZACIJE
OSTANAK NA MONOLITU
Rastući tehnički dug
Rastući coupling
Rastući deployment rizik
BIG-BANG MIGRACIJA
Produženi downtime
Složen rollback
Rizik na nivou cele platforme
Značajan SLA i finansijski rizik
OSNOVNI UZROK I FORENZIKA
Legacy ekosistem bio je izgrađen oko velike Java Enterprise aplikacije koja je koristila Spring i Hibernate, uz centralizovanu relacionu bazu podataka.
Vremenom su poslovne funkcionalnosti postale povezane direktnim pristupom zajedničkim tabelama i stanju baze. Baza podataka je praktično postala istovremeno i persistence sloj i integracioni mehanizam između poslovnih domena.
DUBLJA ARHITEKTONSKA ZAVISNOST
APPLICATION COUPLING
+
SHARED DATA OWNERSHIP
|
v
DIFFICULT DOMAIN EXTRACTION
Izdvajanje aplikacionog koda zato nije automatski značilo i izdvajanje vlasništva nad poslovnim stanjem koje taj kod koristi.
Tradicionalna big-bang migracija zahtevala bi zamrzavanje upisa, transformaciju i migraciju podataka, validaciju ciljnog stanja, prebacivanje produkcionog saobraćaja i monitoring uz mogućnost rollback-a ukoliko nešto pođe po zlu.
BIG-BANG CUTOVER
Freeze Writes
|
v
Transform / Migrate Data
|
v
Validate Target State
|
v
Switch Production Traffic
|
v
Monitor / Roll Back if Required
Za ovu platformu takav pristup bio je operativno neprihvatljiv. Veličina baze i kontinuirani transakcioni saobraćaj činili su kompletnu offline migraciju nepraktičnom, dok bi neuspešan cutover mogao da ostavi aktivne poslovne operacije nedostupnim i stvori veoma složen rollback problem.
Inkrementalni pristup zasnovan na application-level dual-write mehanizmu takođe je bio problematičan. Novi servisi radili bi paralelno sa monolitom, dok bi obe strane održavale kopije poslovnog stanja, čime bi dva sistema istovremeno mogla da upisuju isto poslovno stanje.
DUAL-WRITE FAILURE MODE
Two systems
|
v
Both capable of writing
|
v
Same business state
|
v
Race Conditions
|
v
Data Drift
|
v
Conflicting State
Mrežna latencija, ponovljeni pokušaji, parcijalni kvarovi i različite brzine obrade mogli su dovesti do toga da sistemi vide različite verzije istog zapisa.
Database polling obrasci, poput upita SELECT ... WHERE updated_at > ?, dodavali su kontinuirano opterećenje za sinhronizaciju centralnoj bazi. Pri produkcionim transakcionim volumenima polling je povećavao pritisak na CPU i I/O baze i konkurisao poslovnom opterećenju koje je trebalo da sinhronizuje.
Bidirekcionalna sinhronizacija mogla je dodatno da proizvede feedback loop kada bi upis iz monolita postao change event koji konzumira novi servis, nakon čega bi servis ponovo upisao stanje i izazvao obrnutu sinhronizaciju nazad ka legacy bazi.
KRUŽNA SINHRONIZACIJA
Monolith Write
|
v
Legacy Database
|
v
Change Event
|
v
New Service
|
v
Service Write
|
v
Reverse Sync
|
v
Legacy Database
|
v
[LOOP]
ARHITEKTONSKI UVID I EVOLUCIJA
Servis se ne može bezbedno izdvojiti ako stari i novi sistem istovremeno ostanu autoritativni za istu poslovnu funkcionalnost.
AUTORITATIVNO VLASNIŠTVO
ONE BUSINESS DOMAIN
|
v
ONE AUTHORITATIVE WRITE OWNER
Sistem koji nije vlasnik domena i dalje može sadržati replicirano stanje radi legacy kompatibilnosti, izveštavanja, prelaznih workflow-a, read-side funkcionalnosti ili validacije migracije. Replicirano stanje ne znači i vlasništvo nad upisima.
Legacy model koncentrisao je klijentski saobraćaj u monolitnoj Java Enterprise aplikaciji povezanoj sa velikom relacionom šemom koja je sadržala porudžbine, zalihe, settlement i druge domene sa zajedničkim stanjem i direktnim coupling-om.
LEGACY MODEL: SHARED DATABASE COUPLING
+---------------------------------------------------+
| Client Traffic |
+-------------------------+-------------------------+
|
v
+---------------------------------------------------+
| Monolithic Application |
| Java Enterprise / Spring |
+-------------------------+-------------------------+
|
v
+---------------------------------------------------+
| Massive Relational Schema |
| |
| Orders | Inventory | Settlement | Other Domains |
| |
| Shared State / Direct Coupling |
+---------------------------------------------------+
Redizajnirani model postavio je API Gateway ispred platforme, uveo dinamičko rutiranje po domenu, razdvojio vlasnike autoritativnih upisa i povezao tokove podataka kroz Apache Kafka event mesh.
REDIZAJNIRANI MODEL: STRANGLER FIG + CDC
+---------------------------------------------------+
| Client Traffic |
+-------------------------+-------------------------+
|
v
+---------------------------------------------------+
| API Gateway |
| Dynamic Domain Routing |
+-------------------+-------------------------------+
|
+--------+--------+
| |
v v
+-------------------+ +-------------------+
| Legacy Monolith | | New Domain |
| | | Service |
| Write Owner: A | | Write Owner: B |
+---------+---------+ +---------+---------+
| |
v v
+-------------------+ +-------------------+
| Legacy Database | | Domain Database |
| Domain A | | Domain B |
+---------+---------+ +---------+---------+
|
v
+-------------------+
| Debezium CDC |
| Transaction Log |
+---------+---------+
|
v
+--------------------------------------------+
| Apache Kafka Event Mesh |
| Operation ID | Origin | Ordering Metadata |
+--------------------------------------------+
CHANGE DATA CAPTURE
Umesto ponovljenih upita bazi radi pronalaženja promena, Debezium je direktno povezan sa transakcionim logom baze podataka.
CDC PIPELINE
Legacy Database Transaction
|
v
Transaction Log
|
v
Debezium CDC
|
v
Apache Kafka
|
+--------------------+
| |
v v
New Domain Consumers Legacy Compatibility
Consumers / Adapters
Debezium je hvatao potvrđene promene direktno iz transakcionog loga i objavljivao ih u Apache Kafka event mesh. Novi servisi su konzumirali te promene kako bi održavali sinhronizovano stanje dok je legacy platforma nastavila da obrađuje živi produkcioni saobraćaj.
Time je application-level polling uklonjen iz mehanizma sinhronizacije, a potvrđene promene baze mogle su da budu uhvaćene nezavisno od legacy aplikacionog koda koji je inicijalno izvršio poslovnu operaciju.
Promene koje nastaju i van primarne legacy aplikacione putanje takođe su mogle da učestvuju u CDC pipeline-u, u skladu sa konfigurisanim opsegom capture mehanizma.
DETERMINISTIČKO VLASNIŠTVO NAD PODACIMA
Za svaki poslovni domen tačno jedan sistem bio je autoritativan za upise.
PRIMERI VLASNIŠTVA NAD DOMENIMA
ORDER MANAGEMENT
|
v
Legacy Monolith = WRITE OWNER
INVENTORY FULFILLMENT
|
v
New Service = WRITE OWNER
Vlasništvo nad domenom bilo je eksplicitno i proverljivo.
MIGRACIJA VLASNIŠTVA NAD DOMENOM
Legacy Write Owner
|
v
Synchronize Target State
|
v
Validate Consistency
|
v
Establish Migration Barrier
|
v
Transfer API Routing
|
v
New Service Becomes Write Owner
|
v
Legacy Becomes Replica /
Compatibility Consumer
Novi servis nije mogao postati autoritativan dok je njegovo stanje zaostajalo za stanjem trenutnog vlasnika. Pre prebacivanja vlasništva ciljno stanje bilo je sinhronizovano i validirano.
MIGRACIONA BARIJERA I PRENOS VLASNIŠTVA
MIGRACIONA BARIJERA
LEGACY — AUTORITATIVNI VLASNIK
|
| authoritative writes
v
LEGACY DATABASE
|
v
LEGACY CDC
|
v
KAFKA
|
v
NEW SERVICE
|
v
TARGET STATE SYNCHRONIZED
|
v
CONSISTENCY VALIDATED
|
v
MIGRATION CONDITIONS SATISFIED
|
v
MIGRATION BARRIER
|
v
OWNERSHIP TRANSFER
|
v
NEW SERVICE — AUTORITATIVNI VLASNIK
|
| authoritative writes
v
DOMAIN DATABASE
Pre prenosa vlasništva legacy sistem bio je autoritativan, a promene su kroz CDC i Kafku tekle prema novom servisu. Prenos je obavljen tek kada je ciljno stanje bilo sinhronizovano, konzistentnost validirana i migracioni uslovi ispunjeni.
AUTORITATIVNA PROPAGACIJA PRE I POSLE
PRE PRENOSA:
LEGACY
|
v
CDC -> KAFKA -> NEW SERVICE
POSLE PRENOSA:
NEW SERVICE
|
v
DOMAIN EVENTS / SYNC
|
v
LEGACY COMPATIBILITY STATE
Nakon prenosa vlasništva promenio se smer autoritativne propagacije stanja. Legacy sistem je mogao da zadrži replicirano stanje potrebno preostalim compatibility consumer-ima, ali time nije ponovo dobijao vlasništvo nad upisima.
ANTI-LOOP, IDEMPOTENTNOST I REDOSLED
Događaji sinhronizacije nosili su eksplicitne metapodatke potrebne za razlikovanje autoritativnih operacija od repliciranih promena.
Konzumenti su identifikovali poreklo svakog događaja. Ako bi se replicirani događaj vratio u sistem iz kog je potekao, nije tretiran kao nova lokalna poslovna operacija.
ORIGIN FILTERING
SOURCE = SERVICE_A
|
v
Event -> Kafka -> SERVICE_A
|
v
Origin matches
|
v
Do not re-emit
Isporuka preko Kafke tretirana je kao at-least-once. Konzumenti su zato morali da tolerišu duplu isporuku umesto da pretpostavljaju exactly-once ponašanje na nivou aplikacije.
IDEMPOTENTNA OBRADA
operation_id
|
v
Already Processed?
/ \
YES NO
| |
v v
IGNORE PROCESS
|
v
Record Result
Tamo gde je bio potreban strogi poslovni redosled, korišćene su informacije o redosledu na strani izvora umesto oslanjanja isključivo na wall-clock timestamp-e.
REDOSLED I ZASTARELO STANJE
Incoming Event
|
v
Compare Source Version
/ \
NEWER OLDER
| |
v v
APPLY DISCARD
Vremenske oznake ostale su korisne za dijagnostiku i metapodatke događaja, dok su eksplicitna semantika izvora i verzije korišćene tamo gde je redosled stanja bio značajan.
KLJUČNE INŽENJERSKE ODLUKE
Log-Based CDC umesto application polling-a — Debezium je direktno povezan sa transakcionim logom baze podataka. Time je uklonjeno kontinuirano opterećenje izazvano polling-om i izbegnuta potreba da svaki legacy modul eksplicitno objavljuje događaje sinhronizacije.
Eksplicitno vlasništvo nad podacima domena — Svaka migrirana funkcionalnost imala je tačno jednog autoritativnog vlasnika upisa. Time je uklonjena nejasnoća nastala kada bi dva sistema nezavisno menjala isto poslovno stanje.
API Gateway traffic canarying — API Gateway je postavljen ispred platforme kako bi saobraćaj po domenima mogao da se prebacuje inkrementalno, korišćenjem kontrolisanih routing pravila, bez davanja oba sistema autoritativnog vlasništva nad upisima.
Reverse synchronization adapteri — Preostale legacy funkcionalnosti koje su zavisile od podataka čiji je vlasnik postao novi servis koristile su compatibility adaptere koji konzumiraju domenske događaje i održavaju legacy reprezentaciju potrebnu tim konzumentima.
Idempotentni konzumenti — Kafka konzumenti projektovani su za at-least-once delivery. Stabilni identifikatori operacija i mehanizmi deduplikacije sprečavali su da dupla isporuka proizvede duple poslovne efekte.
Kontrolisani prenos vlasništva — Domen se smatrao migriranim tek nakon sinhronizacije ciljnog stanja, validacije konzistentnosti, ispunjavanja migracionih uslova, prenosa API rutiranja, uspostavljanja vlasništva nad upisima i očuvanja legacy compatibility zahteva.
TRAFFIC CANARY PROGRESSION
1% -> 10% -> 25% -> 50% -> 100%
Prikazani procenti predstavljaju faze inkrementalnog prebacivanja saobraćaja, a ne dozvolu da oba sistema istovremeno obavljaju autoritativne upise za isti domen. Konkretan tok migracije zavisio je od ponašanja domena, rezultata validacije i operativnog nivoa pouzdanosti. Vlasništvo nad upisima ostajalo je jednoznačno tokom svih faza.
Neke preostale legacy funkcionalnosti nastavile su da zavise od podataka čiji su vlasnici postali novi servisi. Compatibility adapteri su zato konzumirali domenske događaje i održavali legacy reprezentaciju potrebnu tim konzumentima, bez vraćanja vlasništva nad upisima legacy sistemu.
Migracija je projektovana oko bezbednog replay-a. Stabilni identifikatori operacija i mehanizmi deduplikacije obezbedili su da at-least-once delivery ne proizvodi duple poslovne efekte.
ARHITEKTONSKI ISHOD
Migracija je promenila platformu iz centralizovanog modela sa zajedničkim stanjem i snažnim coupling-om u model sa eksplicitnim vlasništvom nad domenima.
PRE
Monolithic Application
|
v
Shared Relational Database
|
v
Cross-Domain Coupling
|
v
Platform-Wide Deployment Risk
POSLE
+-------------------+ +-------------------+
| Legacy Domain A | | New Domain B |
| | | |
| Write Owner A | | Write Owner B |
+---------+---------+ +---------+---------+
| |
v v
+-------------------+ +-------------------+
| Legacy Database | | Domain Database |
+---------+---------+ +---------+---------+
| |
v v
+------------------------------------------------+
| Apache Kafka Event Mesh |
| |
| Legacy CDC / Domain Events / Replication |
+------------------------------------------------+
Monolit nije zamenjen jednom operacijom. Postepeno je smanjivan. Svaki izdvojeni domen uklanjao je još jednu zavisnost iz monolitne arhitekture dok je preostali sistem nastavljao da radi.
Modernizacija i razvoj novih funkcionalnosti zato su mogli da napreduju bez vezivanja svake promene za stabilnost kompletne legacy platforme.
KVANTIFIKOVANI REZULTATI
Planirani downtime migracije
PRE
Planirani prozori održavanja
POSLE
0,0 minuta
Nije bilo planiranog downtime-a za migraciju
Kontencija zaključavanja baze
PRE
Početno stanje
POSLE
40% smanjenje
Smanjena kontencija zaključavanja baze
Učestalost deployment-a
PRE
Približno jedno izdanje na osam nedelja
POSLE
Dnevna nezavisna izdanja
Dnevna izdanja za nezavisno migrirane servise
Odstupanje podataka
PRE
Migracioni rizik
POSLE
Nije detektovano
Tokom migracije nije detektovano nerešeno odstupanje podataka
Produkciona SLA kršenja
PRE
Tokom migracije
POSLE
0
Tokom migracije nisu zabeležena produkciona SLA kršenja
Program modernizacije trajao je približno osam meseci, tokom kojih je platforma nastavila da opslužuje produkcioni saobraćaj.
Nije bio potreban planirani prekid rada radi migracije. Kontencija zaključavanja baze smanjena je za 40%, a tokom migracije nije detektovano nerešeno odstupanje podataka.
Učestalost deployment-a povećana je sa približno jednog izdanja na osam nedelja na dnevna izdanja za nezavisno migrirane servise.
Tokom migracije nisu zabeležena produkciona SLA kršenja.
Osmomesečna modernizacija omogućila je izdvajanje poslovnih funkcionalnosti dok je platforma nastavila da opslužuje produkcioni saobraćaj. Izmereni ishodi obuhvatili su 0,0 minuta planiranog downtime-a za migraciju, 40% manje kontencije zaključavanja baze, odsustvo detektovanog nerešenog odstupanja podataka, dnevna nezavisna izdanja umesto približno jednog izdanja na osam nedelja i nula zabeleženih produkcionih SLA kršenja tokom migracije.
INŽENJERSKI DOPRINOS
SWARCS je sproveo arhitektonsku forenziku legacy aplikacije i njenih zavisnosti od baze podataka, definisao strategiju modernizacije, projektovao model determinističkog vlasništva nad podacima i implementirao mehanizme sinhronizacije i migracije potrebne za bezbedno izdvajanje poslovnih domena dok je platforma ostajala pod kontinuiranim produkcionim opterećenjem.
ODGOVORNOSTI
Sprovedena forenzička analiza legacy aplikacije i njenih zavisnosti od baze podataka
Identifikovano zajedničko vlasništvo nad podacima kao dublja granica coupling-a od samog monolitnog codebase-a
Definisane eksplicitne granice vlasništva nad podacima
Projektovana Strangler Fig migraciona arhitektura
Projektovan i implementiran Debezium Change Data Capture pipeline
Integrisani CDC događaji kroz Apache Kafka
Projektovani origin filtering i anti-loop mehanizmi
Projektovana idempotentna obrada događaja za at-least-once delivery
Definisana pravila sinhronizacije i redosleda na strani izvora
Projektovani kontrolisani prenosi vlasništva nad upisima
Implementirani compatibility i reverse-synchronization adapteri
Implementirano inkrementalno API rutiranje i prebacivanje produkcionog saobraćaja
Definisani mehanizmi migracione validacije i reconciliation-a
Očuvani legacy compatibility zahtevi tokom izdvajanja domena
Sproveden približno osmomesečni program modernizacije pod kontinuiranim produkcionim opterećenjem
KLJUČNA PORUKA
SINHRONIZACIJA MOŽE BITI BIDIREKCIONALNA. VLASNIŠTVO NAD PODACIMA NE SME BITI.
Eksplicitno vlasništvo nad podacima
Sinhronizacija stanja
Transaction-log CDC
Origin filtering
Source-side ordering
Idempotentna obrada
API rutiranje
Migracione barijere
Failure i replay ponašanje
Inkrementalno izdvajanje domena
Legacy modernizacija ne zahteva visokorizičan Big Bang cutover. Teži deo nije izgradnja novog servisa, već promena vlasništva nad produkcionim stanjem bez stvaranja dva konkurentna autoriteta. Bezbedna modernizacija zato zahteva eksplicitnu kontrolu nad vlasništvom nad podacima, sinhronizacijom stanja, API rutiranjem, prenosom vlasništva i ponašanjem tokom failure i replay scenarija. Kombinovanjem transaction-log-based CDC-a, Apache Kafka-e, determinističkog vlasništva nad domenima, idempotentne obrade i Strangler Fig obrasca, SWARCS je omogućio da platforma evoluira inkrementalno dok ostaje operativna pod kontinuiranim produkcionim opterećenjem. Monolit je postepeno razgrađivan izdvajanjem jedne poslovne funkcionalnosti za drugom, pri čemu je svaka tranzicija uspostavljala novu eksplicitnu granicu vlasništva.
