I recently talked about using glue services (Anti-Corruption Layers) to isolate modern platforms from legacy integrations.
Today I want to talk about another type of glue service: data synchronization services.
🗃️ The Real Modernization Problem
One of the hardest parts of replacing a legacy platform is usually not the application itself.
It’s the data.
In a perfect world, you could: take downtime, export the database, import it into the new platform, and switch traffic.
Simple.
But large downtime windows are increasingly rare. And big-bang migrations are risky enough that many organizations actively avoid them.
That means old and new systems often need to run side-by-side for a while.
Both platforms stay active.
Both serve customers.
Both need access to the same data. This is where modernization becomes difficult.
🔄 Keeping Two Systems in Sync
When you are changing both the application and the underlying database, keeping data synchronized becomes difficult very quickly.
Especially when the two systems use different schemas, database technologies, data models, and update patterns.
You can’t simply export/import anymore. You need continuous synchronization.
👨🏻🤝👨🏾 Enter the Synchronization Service
One useful pattern is to build a dedicated synchronization service whose sole responsibility is to keep data aligned across systems.
How synchronization works depends entirely on the platform.
I’ve used several approaches over the years.
⚙️ Database Triggers
One approach is to use database triggers or change-capture mechanisms in the legacy system.
When data changes, it’s detected, the synchronization service processes it, and the new platform is updated.
📩 Event-Based Synchronization
Another approach is to have the legacy platform emit events via a message broker.
The synchronization service consumes those events and updates the new database/platform accordingly. This tends to work especially well when modernizing toward event-driven systems.
⏳ Temporary Infrastructure
The important thing to remember is that these synchronization services are usually temporary. Their job is not to become a permanent platform.
Their purpose is to enable safe migration while reducing downtime and risk.
Once the migration is complete, the glue service disappears.
⚠️ One Important Warning
Bi-directional synchronization becomes extremely difficult very quickly.
With bi-directional synchronization, you have to solve:
Conflict resolution
Consistency problems
Update ordering
Partial failures
Whenever possible, avoid bi-directional synchronization.
In many cases, it is simpler to migrate the application layer first, then the database layer.
🧐 Final Thought
Modernization is rarely just replacing code. A major challenge is safely bridging old and new systems during transition periods.
Synchronization glue services are often what make zero-downtime migrations possible.
Originally posted on #Bengineering.
If this hit home, share the original with someone who needs it: Glue Services: Part Two — Data Synchronization
More from #Bengineering
When modernizing legacy systems, don’t be afraid to build glue services
The first part explains how edge translation services keep legacy integrations from shaping the new platform.Have you heard of Store and Forward?
Durable handoff patterns matter when systems need to bridge failures and asynchronous workflows.Does resource usage within your application or database suddenly spike periodically?
Jitter is a simple way to reduce operational spikes in scheduled or repeated work.You can have 100% Code Coverage and still have ticking time bombs in your code.
Migrations need tests that cover failure paths, not only confidence metrics.
More from Latency Slayer
In-Flight Request Tracking: Lessons from Card Payments and HTTP/2
A deeper look at correlation, timeouts, and correctness in asynchronous systems.Are Atomic Operations Faster and Better Than a Mutex? It Depends
A practical comparison of concurrency primitives and their correctness tradeoffs.