A new engineer joins your company on Monday morning. HR created her account on Friday. She opens her collaboration suite, tries to join her team’s channel, and gets an error. Her manager files a ticket. IT confirms the account exists in the directory. It just hasn’t propagated yet. “Give it a day.”
That sentence, give it a day, is the sound of a sync architecture built for a different era. And most enterprises are still running on it.
The Problem at Enterprise Scale
Identity data is the connective tissue of every enterprise platform. Who you are, which teams you belong to, what you’re allowed to see, every application downstream depends on that data being correct. When it lags by hours, the damage is quiet but constant.
The obvious cost is the locked-out employee. A new hire who can’t access tools on day one isn’t just annoyed; they’re idle, and their manager is now spending time on access issues instead of onboarding. Multiply that across a company hiring hundreds of people a month and the lost hours become a real line item. Support queues fill with tickets that have the same root cause and the same non-answer: wait for the next sync cycle.
The less obvious cost is on the security side, and it’s worse. If provisioning is slow, deprovisioning is slow too. An employee who left at noon may still have working access at midnight. In a world of compliance audits and least-privilege mandates, “the sync runs every 24 hours” is not an acceptable answer to “when was this person’s access revoked?”
What makes this problem dangerous is that it’s invisible until it compounds. No single delayed sync triggers an incident review. Each one is a shrug. But the shrug scales with the organization, and at some point the aggregate, the support overhead, the audit findings, the day-one friction, is large enough that someone finally asks why the system works this way.
The Industry Pattern That’s Breaking
The answer is usually: because pull-based sync was the reasonable design when the system was built. A downstream service periodically asks the identity provider, “what changed?”, hourly, nightly, whatever cadence the directory can tolerate. It’s simple, it’s easy to reason about, and it worked fine when the tenant had fifty thousand users.
It does not work fine at hundreds of millions. I saw this firsthand at a company, where I owned my company’s service for software. Pull-based sync at that scale has a brutal arithmetic: to keep data fresh, you poll more often; polling more often hammers the directory; the directory throttles you; throttling makes data staler, which creates pressure to poll harder. You end up scanning enormous user populations to find the small fraction that actually changed. Most of the compute is wasted rediscovering things you already know.
The business feels this in three ways. First, latency: our sync delays could stretch to 24 hours, which meant a full day of the problems described above. Second, fragility: full-scan sync jobs are exactly the kind of workload that fails at 2 a.m. and pages an engineer. Third, opportunity cost: some of your best people end up permanently assigned to firefighting a system whose fundamental design guarantees more fires.
The Shift to Event-Driven Identity
The fix is to invert the model. Instead of downstream systems asking “what changed?”, the identity provider tells them, a change happens, an event fires, subscribers react. Push, not pull.
When we redesigned the software of the company’s event-driven model, identity sync latency dropped from up to 24 hours to under 60 seconds, for a population of over 300 million users. That’s not an incremental improvement; it’s a different product. The new hire is in her team channels before her first coffee. The departed employee’s access dies within a minute of the HR action. Group membership changes show up while the meeting that prompted them is still going.
Compliance gets simpler too. GDPR and similar regimes care about how quickly personal data changes and deletions propagate through your systems. An event-driven pipeline gives you an honest, auditable answer measured in seconds, along with a clean record of what changed and when.
The part I want leaders to internalize: this outcome came from design, not from spending. We didn’t buy our way to 60 seconds by provisioning ten times the infrastructure to poll ten times harder, that path leads to throttling anyway. Processing only the changes, rather than rescanning everything to find them, meant the system did dramatically less work while delivering dramatically fresher data. Better architecture and lower cost were the same decision.
What Leaders Should Take Away
If you’re a CTO or engineering leader, a few questions are worth asking this quarter:
How long does it actually take for an identity change to reach every system that depends on it? Not the SLA on paper, the observed number, at p99, on a bad day. If nobody can answer, that’s the first finding.
How much engineering time goes into keeping sync alive? Throttling workarounds, retry logic, backfill jobs, incident response. That’s the recurring tax of the pull model, and it usually hides across several teams’ budgets.
And increasingly: what is stale identity data doing to your AI initiatives? This one is new and underappreciated. Every enterprise is now feeding organizational data into models and agents, for search, for automation, for access decisions. If the identity layer is a day behind, your AI systems are reasoning about an org that no longer exists. They’ll route requests to people who changed teams, surface documents to people who should have lost access, and personalize experiences against outdated profiles. Real-time identity is quietly becoming an AI-readiness requirement, because intelligence built on stale data is confidently wrong.
One caution: don’t lead with cost savings. In my experience, both on the software redesign and in later cost-optimization work at my company, savings are what good architecture produces as exhaust. If you set out to cut the sync bill, you’ll trim polling frequency and make the staleness problem worse. If you set out to make the data correct and fresh, the waste disappears on its own, because the waste was the polling.
The Bottom Line
Real-time identity sync used to be a luxury. It’s now table stakes. Employees expect access to follow them instantly, security teams expect revocation to be immediate, regulators expect propagation to be provable, and AI systems expect the data underneath them to be true.
The organizations that get ahead of this will do it deliberately, on their own timeline, as an architecture decision. The ones that don’t will do it anyway, after the audit finding, or the outage, or the incident report where a terminated account was used eighteen hours after termination. The engineering is well understood. The only question is whether you make the change before or after it’s forced on you.
