An enterprise integration platform connects to many customer identity systems with different reliability and behaviour. How should directory sync, SSO and webhook processing be isolated?

The defining constraint

Every customer's identity system is different, operated by someone else, and unreliable in its own way. One directory is slow, another returns malformed data, a third rate-limits aggressively, a fourth is only reachable through a VPN that a customer's network team changes without notice.

The architecture's primary job is to prevent that variance from becoming your instability.

The isolation required

• Per-tenant, per-connection workers and queues. A customer's slow or broken directory must not consume shared capacity. This is the single most important structural decision.
• Per-connection scheduling with independent intervals. A directory of fifty users and one of a hundred thousand need different sync cadences and different strategies — full versus incremental — and one schedule serves neither.
• Per-connection circuit breakers and error budgets, with a connection disabled and its owner notified when it exceeds them, rather than retrying indefinitely against a system that is not coming back.
• Checkpointing, so a sync interrupted at 80% resumes rather than restarting. For a large directory that is the difference between an hour and a day.
• Schema tolerance. Directory data will contain nulls in mandatory fields, duplicate identifiers, values exceeding documented lengths and encodings nobody expected. Reject the record, quarantine it, continue the sync — a single malformed user must not fail the whole run, which is the most common naive implementation.

The correctness problem underneath

Synchronisation means two systems disagreeing, continuously. The design decisions:

• The customer's directory is authoritative, always, and your copy is a cache with a staleness bound.
• Deletions are the dangerous case. A directory that returns an empty result because of an error looks identical to one where everyone was removed. A safety threshold — refuse to process a deletion batch above some proportion of the population without confirmation — is not optional, and its absence has produced some of the most damaging incidents in this category.
• Reconciliation independent of the event stream, because SCIM events are lost, arrive out of order, and are sometimes simply not sent by the customer's system.

The product consequence

A capability and reliability matrix per connection type is a feature, not internal documentation. Customers need to know which behaviours are supported by their identity provider, and support engineers need to know which are known-unreliable before they start investigating.