When systems fail, it’s rarely because a single component stopped working. It’s usually because the connections between systems weren’t designed to handle real-world conditions.

Most of my work involves building and maintaining integrations across identity systems, directories, authentication platforms, and internal applications. Over time, a pattern becomes clear:

It’s not the systems that break first — it’s the assumptions between them.

A few common failure points:

Implicit dependencies

• System A assumes System B is always available.
• System B assumes System C is always consistent.
• None of those assumptions is documented — until something fails.

Inconsistent data models

Different systems represent identity, roles, and state differently. Without a normalization layer, you end up with mismatches that create subtle, hard-to-debug issues.

Lack of idempotency

Retry logic without idempotency leads to duplication, corruption, or a conflicting state. This shows up quickly in provisioning and synchronization flows.

No clear source of truth

When multiple systems can modify the same data, conflicts are inevitable. You need clearly defined ownership of data and state transitions.

Poor observability across boundaries

Each system may have logging, but without end-to-end visibility, tracing issues across systems becomes extremely difficult.

---

The takeaway:

• Designing systems is important.
• Designing how systems interact is critical.

That’s where most real-world complexity — and most real-world failures — actually live.