A large-scale Enterprise Supply Chain & Logistics platform faced severe modernization constraints due to a tightly coupled Java Enterprise monolith bound to a massive relational database schema. The platform operated continuously under production load, while contractual financial penalties made planned downtime commercially unacceptable. Forensic analysis showed that business domains lacked explicit data ownership and remained coupled through direct access to shared database state. Earlier application-level dual writes and database polling introduced additional failure modes including database contention, race conditions, data drift, duplicate processing, and circular synchronization loops.
SOLUTION
SWARCS redesigned the modernization strategy around one authoritative write owner per business domain, transaction-log-based Change Data Capture instead of application polling, and incremental traffic migration using the Strangler Fig pattern. Debezium captured committed database changes directly from the transaction log and published them to an Apache Kafka event mesh. New services consumed these changes to maintain synchronized state while the legacy platform continued serving live traffic. When a domain was ready for extraction, write ownership was transferred through a controlled migration barrier and dynamic API routing.
CORE ARCHITECTURAL SHIFT
FROM
Business domains coupled through a Java Enterprise monolith and shared relational database state, with ambiguous write ownership and platform-wide migration dependencies
→
TO
Explicit domain data ownership with one authoritative write owner per capability, transaction-log CDC, Kafka-based synchronization, and incremental Strangler Fig traffic migration
CONCLUSION
The eight-month modernization program decoupled core business capabilities while the platform continued serving production traffic. No planned migration downtime was required, database lock contention was reduced by 40%, no data drift was detected, deployment frequency moved from approximately every 8 weeks to daily independent releases, and no production SLA breaches were observed during the migration.
ARCHITECTURAL ANALYSIS
CONTEXT & BUSINESS IMPACT
The platform is an Enterprise B2B Core Transaction & Supply Chain Logistics system managing end-to-end supply chain operations, order processing, inventory tracking, and financial transaction settlement across thousands of integrated enterprise partners.
The platform operates under sustained throughput of approximately 6,500 TPS, with daily peak traffic reaching approximately 12,000 TPS against a centralized relational database.
The platform operates as a 24/7/365 business-critical service. Contractual obligations impose severe financial penalties for outages and unplanned or extended maintenance windows.
No planned platform shutdown for migration
No practical opportunity for a prolonged database write freeze
Release cycles occurring approximately every 8 weeks and requiring cross-team coordination
Inability to extract individual capabilities without preserving legacy dependencies
Platform-wide blast radius for deployment or migration failures
The organization was effectively trapped between two unacceptable choices: remaining on the monolith with increasing technical debt, coupling, and deployment risk, or performing a big-bang migration involving extended downtime, large rollback complexity, platform-wide blast radius, and significant SLA and financial risk.
The Modernization Constraint
REMAIN ON THE MONOLITH
Increasing technical debt
Increasing coupling
Increasing deployment risk
PERFORM A BIG-BANG MIGRATION
Extended downtime
Large rollback complexity
Platform-wide blast radius
Significant SLA and financial risk
THE ROOT CAUSE & FORENSICS
The legacy ecosystem was built around a large Java Enterprise application using Spring and Hibernate and a centralized relational database.
Over time, business capabilities became coupled through direct access to shared database tables and state. The database had effectively become both the persistence layer and the integration mechanism between business domains.
The Deeper Architectural Dependency
APPLICATION COUPLING
+
SHARED DATA OWNERSHIP
|
v
DIFFICULT DOMAIN EXTRACTION
Extracting application code therefore did not automatically extract ownership of the underlying business state.
A traditional big-bang migration would require freezing writes, transforming and migrating data, validating target state, switching production traffic, and monitoring the result with rollback available if required.
Big-Bang Cutover
Freeze Writes
|
v
Transform / Migrate Data
|
v
Validate Target State
|
v
Switch Production Traffic
|
v
Monitor / Roll Back if Required
For this platform, that approach was operationally unacceptable. The database size and continuous transaction volume made a complete offline migration impractical, while a failed cutover could leave active business operations unavailable and create a complex rollback problem.
An incremental approach using application-level dual writes was also problematic. New services operated alongside the monolith while both sides maintained copies of business state, creating two systems capable of writing the same business state.
Dual-Write Failure Mode
Two systems
|
v
Both capable of writing
|
v
Same business state
|
v
Race Conditions
|
v
Data Drift
|
v
Conflicting State
Network latency, retries, partial failures, and different processing speeds could cause the systems to observe different versions of the same record.
Database polling patterns such as SELECT ... WHERE updated_at > ? were used to locate changes. At production transaction volumes, polling increased database CPU and I/O pressure and competed with the business workload it was intended to synchronize.
Bidirectional synchronization could additionally create feedback loops when a monolith write became a change event consumed by a new service, which then wrote the state back and caused reverse synchronization into the legacy database.
Circular Synchronization
Monolith Write
|
v
Legacy Database
|
v
Change Event
|
v
New Service
|
v
Service Write
|
v
Reverse Sync
|
v
Legacy Database
|
v
[LOOP]
ARCHITECTURAL INSIGHT & EVOLUTION
A service cannot be safely extracted if both the old and new systems remain authoritative for the same business capability.
Authoritative Ownership
ONE BUSINESS DOMAIN
|
v
ONE AUTHORITATIVE WRITE OWNER
A non-owning system could still contain replicated state for legacy compatibility, reporting, transitional workflows, read-side functionality, or migration validation. Replicated state did not imply write ownership.
The legacy model concentrated client traffic in a monolithic Java Enterprise application connected to a massive relational schema containing orders, inventory, settlement, and other domains with shared state and direct coupling.
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 |
+---------------------------------------------------+
The redesigned model placed an API Gateway in front of the platform and used domain-based routing to direct requests to the system responsible for each capability. Extracted domains had their own write owners and databases. CDC from the legacy database fed committed changes into Kafka, while domain events supported synchronization with remaining legacy compatibility consumers.
Redesigned Model: Strangler Fig + CDC
+---------------------------------------------------+
| Client Traffic |
+-------------------------+-------------------------+
|
v
+---------------------------------------------------+
| API Gateway |
| 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 |
+----------------------+---------------------+
|
+--------------------+--------------------+
| |
v v
New Domain Consumers Legacy Compatibility
Consumers / Adapters
The diagram distinguishes the legacy database's transaction-log CDC path from the Kafka event consumers. It does not imply that both systems are authoritative for the same domain. Each domain retains one authoritative write owner; replicated state in another system does not confer write authority.
CHANGE DATA CAPTURE
Instead of repeatedly querying the database for changes, Debezium was connected directly to the database transaction log.
CDC Pipeline
Legacy Database Transaction
|
v
Transaction Log
|
v
Debezium CDC
|
v
Apache Kafka
|
+-------------+-------------+
| |
v v
New Domain Consumers Legacy Compatibility
Consumers / Adapters
Debezium captured committed database changes directly from the transaction log and published them to an Apache Kafka event mesh. New services consumed these changes to maintain synchronized state while the legacy platform continued serving live traffic.
This removed application-level polling from the synchronization mechanism and allowed committed database changes to be captured independently of the legacy application code path.
It also allowed changes originating outside the primary legacy application path to participate in the CDC pipeline, subject to the configured capture scope.
DETERMINISTIC DATA OWNERSHIP
For each business capability, exactly one system was authoritative for writes.
Domain Ownership Examples
ORDER MANAGEMENT
|
v
Legacy Monolith = WRITE OWNER
INVENTORY FULFILLMENT
|
v
New Service = WRITE OWNER
The ownership of a domain was therefore explicit and observable.
Domain Ownership Migration
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
The new service could not become authoritative while its state was still behind the current owner. Before ownership transfer, the target state was synchronized and validated.
MIGRATION BARRIER & OWNERSHIP TRANSFER
Migration Barrier
LEGACY: AUTHORITATIVE WRITE OWNER
|
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: WRITE OWNER
|
v
DOMAIN DATABASE
Before ownership transfer, the legacy system remained the authoritative write owner and committed changes propagated through CDC and Kafka toward the new service. The target state had to be synchronized and consistency validated before the new service could become authoritative.
Authoritative Propagation Before and After
BEFORE OWNERSHIP TRANSFER:
LEGACY
|
v
CDC
|
v
KAFKA
|
v
NEW SERVICE
(replicated state)
AFTER OWNERSHIP TRANSFER:
NEW SERVICE
|
v
DOMAIN DATABASE
|
v
DOMAIN EVENTS / SYNC
|
v
LEGACY COMPATIBILITY STATE
Only one side remained authoritative for business writes. The legacy system could retain replicated state required by remaining compatibility consumers without regaining write ownership.
ANTI-LOOP, IDEMPOTENCY & ORDERING
Synchronization events carried explicit metadata required to distinguish authoritative operations from replicated changes.
Consumers identified the origin of every event. If a replicated event returned to its originating system, it was not treated as a new local business operation.
Origin Filtering
SOURCE = SERVICE_A
|
v
Event -> Kafka -> SERVICE_A
|
v
Origin matches
|
v
Do not re-emit
Kafka delivery was treated as at-least-once. Consumers therefore had to tolerate duplicate delivery rather than assuming exactly-once application behavior.
Idempotent Processing
operation_id
|
v
Already Processed?
/ \
YES NO
| |
v v
IGNORE PROCESS
|
v
Record Result
Where strict business ordering was required, source-side ordering information was used rather than relying solely on wall-clock timestamps.
Ordering & Staleness
Incoming Event
|
v
Compare Source Version
/ \
NEWER OLDER
| |
v v
APPLY DISCARD
Timestamps remained useful for diagnostics and event metadata, while explicit source and version semantics were used where state ordering was significant.
KEY ENGINEERING DECISIONS
Log-Based CDC Over Application Polling — Debezium was connected directly to the database transaction log. This removed continuous polling and avoided requiring every legacy module to explicitly publish synchronization events.
Explicit Domain Data Ownership — Each migrated capability received exactly one authoritative write owner. This eliminated the ambiguity of two systems independently modifying the same business state.
API Gateway Traffic Canarying — The API Gateway was positioned in front of the platform so domain traffic could be transitioned incrementally using controlled routing rules, without granting both systems authoritative write ownership.
Reverse Synchronization Adapters — Remaining legacy capabilities that depended on data owned by newly extracted services used compatibility adapters consuming domain events and maintaining the legacy representation required by those consumers.
Idempotent Consumers — Kafka consumers were designed for at-least-once delivery. Stable operation identifiers and deduplication mechanisms prevented duplicate delivery from producing duplicate business effects.
Controlled Ownership Transition — A domain was considered migrated only after target synchronization, consistency validation, migration conditions, API routing transfer, write-ownership establishment, and preservation of legacy compatibility.
Traffic Canary Progression
1% -> 10% -> 25% -> 50% -> 100%
The exact traffic progression depended on domain behavior, validation results, and operational confidence. The percentages describe incremental traffic rollout; they do not imply that the legacy system and the new service may both accept authoritative writes for the same domain. The domain's write ownership remains singular throughout the migration.
Some remaining legacy capabilities continued to depend on data owned by newly extracted services. Compatibility adapters therefore consumed domain events and maintained the legacy representation required by those consumers without returning write ownership to the legacy system.
The migration was designed around safe replay. Stable operation identifiers and deduplication mechanisms ensured that at-least-once delivery did not create duplicate business effects.
ARCHITECTURAL OUTCOME
The migration changed the platform from centralized shared-state coupling to explicit domain ownership.
Before
Monolithic Application
|
v
Shared Relational Database
|
v
Cross-Domain Coupling
|
v
Platform-Wide Deployment Risk
After
Client Traffic
|
v
API Gateway
/ \
/ \
v v
Legacy New Service
Owner A Owner B
| |
v v
Legacy Domain DB
| |
+----+----+
|
v
Kafka Event Mesh
|
v
CDC / Replication
The monolith was not replaced in a single operation. It was progressively reduced. Each extracted domain removed another dependency from the monolithic architecture while the remaining system continued operating.
Modernization and feature delivery could therefore proceed without coupling every change to the stability of the entire legacy platform.
QUANTIFIED RESULTS
Planned Migration Downtime
BEFORE
Planned maintenance windows
AFTER
0.0 minutes
No planned migration downtime
Database Lock Contention
BEFORE
Baseline
AFTER
40% reduction
Reduced database lock contention
Deployment Frequency
BEFORE
Approximately every 8 weeks
AFTER
Daily independent releases
Daily releases for independently migrated services
Data Drift
BEFORE
Migration risk
AFTER
No detected data drift
No unreconciled data drift detected during migration
Production SLA Breaches
BEFORE
Baseline
AFTER
0 during migration
No observed production SLA breaches during migration
The approximately eight-month modernization program decoupled core business capabilities while the platform continued serving production traffic.
No planned migration shutdown was required. Database lock contention was reduced by 40%, while no data drift was detected during the migration.
Deployment frequency increased from releases approximately every 8 weeks to daily releases for independently migrated services.
No production SLA breaches were observed during the migration.
A major architectural outcome was a reduction in the blast radius of change. Modernization and feature delivery could proceed without coupling every change to the stability of the entire legacy platform.
The approximately eight-month modernization changed a continuously operating enterprise platform from centralized shared-state coupling toward explicit domain ownership. The result was 0.0 minutes of planned migration downtime, 40% lower database lock contention, no detected data drift, daily independent releases instead of releases approximately every 8 weeks, and 0 observed production SLA breaches during the migration.
ENGINEERING CONTRIBUTION
SWARCS performed the architectural forensics, defined the modernization strategy, designed the deterministic data ownership model, and implemented the synchronization and migration mechanisms required to extract business domains safely while the platform remained under continuous production load.
RESPONSIBILITIES
Performed forensic analysis of legacy application and database dependencies
Identified shared data ownership as a deeper coupling boundary than the monolithic codebase
Defined explicit data ownership boundaries
Designed the Strangler Fig migration architecture
Designed the Debezium Change Data Capture pipeline
Integrated CDC events through Apache Kafka
Designed origin filtering and anti-loop semantics
Designed idempotent event processing for at-least-once delivery
Defined synchronization and source-side ordering rules
Designed controlled write-ownership transitions
Designed compatibility and reverse-synchronization adapters
Designed incremental API routing and production traffic migration
Defined migration validation and reconciliation mechanisms
Maintained legacy compatibility requirements during domain extraction
Executed an approximately eight-month modernization program under continuous production load
KEY TAKEAWAY
SYNCHRONIZATION MAY BE BIDIRECTIONAL. DATA OWNERSHIP MUST NOT BE.
Explicit data ownership
State synchronization
Transaction-log CDC
Origin filtering
Source-side ordering
Traffic routing
Migration barriers
Idempotent processing
Failure and replay behavior
Incremental domain extraction
Legacy modernization does not require a high-risk Big Bang cutover. The difficult part is not creating the new service; it is changing ownership of production state without creating two competing authorities. A safe modernization architecture therefore needs explicit control over data ownership, state synchronization, traffic routing, ownership transition, and failure and replay behavior. By combining transaction-log-based CDC, Apache Kafka, explicit domain ownership, origin filtering, source-side ordering, idempotent processing, and the Strangler Fig pattern, SWARCS enabled the platform to evolve incrementally while remaining operational under continuous production load. The monolith was progressively dismantled by moving one business capability at a time, with each transition establishing a new explicit boundary of ownership.
