All articles
TechnicalFebruary 20266 min read

Your Integration Runs Every Hour and Prays

And hopes nothing changed in those 59 minutes.

Somewhere in your infrastructure, a cron job runs every 60 minutes. Its job is to connect System A to System B. It pulls data from one, transforms it, and pushes it to the other. It was written by a developer who left two years ago. It runs on a server that nobody has rebooted since. It works. Mostly.

At minute 0, the sync runs. It copies your inventory from your warehouse system to your sales tool. At minute 12, a device sells. The warehouse system marks it as sold. The sales tool doesn't know yet — it won't know until minute 60. At minute 35, a buyer in the sales tool sees the device, thinks it's available, and starts a negotiation. At minute 47, the buyer makes an offer on a device that was sold 35 minutes ago.

At minute 60, the sync runs again. The device disappears from the sales tool. The buyer's offer now references a ghost. Someone has to make a phone call. The phone call begins with "I'm sorry, that device is no longer available" and ends with the buyer wondering why your inventory is always wrong.

The 59-Minute Gap

Every sync-based integration has a gap — the time between when something changes in one system and when the other system knows about it. For hourly syncs, that gap is up to 59 minutes. For daily syncs, it's 23 hours and 59 minutes. For the integration that "usually runs nightly but sometimes fails and nobody checks until someone complains," the gap is existential.

The gap isn't a bug. It's the architecture. Sync jobs copy a snapshot. Between snapshots, the world changes. Devices sell. Grades update. Orders ship. Prices adjust. The sync doesn't know about any of it until it runs again, looks at the source, and copies the current state. Everything that happened between the last sync and this one is compressed into a single update. The granularity of change is lost. The sequence of events is lost. Only the end state remains.

A sync job doesn't integrate two systems. It gives them a shared memory that updates once an hour and hopes the hour was uneventful.

The Error You Don't See

When a sync job succeeds, nobody notices. When it fails, sometimes nobody notices either. The job runs, hits a timeout, logs an error to a file that nobody monitors, and the two systems quietly diverge. Inventory in System A says 47 devices. Inventory in System B says 52. The difference: five devices that were processed during the sync failure. By the time someone notices — usually because a buyer asks about a device that exists in one system but not the other — the data has diverged far enough that reconciliation requires manual work.

Manual reconciliation of diverged systems is one of those tasks that everyone agrees is terrible and nobody tracks the cost of. It takes an hour. Or three hours. Or a full day, depending on how long the sync was broken and how many changes accumulated. It's always urgent because someone is waiting on the data. It's always frustrating because it's not "real" work — it's work created by infrastructure that didn't work.

The Alternative

The alternative to sync-based integration is event-based integration: when something changes, the change is communicated immediately. A device sells — every connected system knows within seconds. A grade updates — the listing reflects it instantly. An order ships — the client portal shows the tracking number before the warehouse operator has put down the scanner.

This isn't aspirational. This is what happens when your systems share a database instead of copying data between databases. When the warehouse, the sales tool, the client portal, and the settlement engine all read from and write to the same source of truth, there's no sync gap because there's nothing to sync. The data is already there. It's always current. Nobody has to pray.


Your integration runs every hour. In that hour, your warehouse changes. Your inventory changes. Your sales pipeline changes. And your integration, faithfully, ignores all of it until the clock says it's time to look. The cron job is not a solution. It's a coping mechanism for systems that should have been one system all along.

Like what you read?

Founding members get every article first, plus 12 months free access to the platform.

Get Early Access