Design an Identity & Access Management System

Problem statement

Design an identity and access management (IAM) platform that owns the central user directory, authenticates humans and workloads with multi-factor assurance, authorizes every request through role-, attribute-, and relationship-based policies, federates single sign-on over OIDC and SAML to hundreds of relying parties, and manages the full account lifecycle from provisioning to deprovisioning with an immutable audit trail.

IAM is unusual because it is simultaneously a hot data path and a security boundary. Every login, every service-to-service call, and every admin change touches it. If the token service degrades, every product degrades; if the policy engine is wrong, the breach is silent and total. The design must therefore separate four planes and give each different consistency, latency, and failure behavior.

1. Authentication plane: credential verification, MFA orchestration, session establishment, token issuance.
2. Authorization plane: policy storage, evaluation, decision caching, and enforcement-point integration.
3. Federation and lifecycle plane: OIDC/SAML trust, SCIM provisioning, joiner-mover-leaver workflows, deprovisioning.
4. Governance plane: keys, audit, compliance evidence, admin control, break-glass.

Why this problem is distinctive

A feed system can serve stale content; IAM cannot serve a stale denial or a fresh acceptance by mistake. Authorization decisions are security decisions with microsecond budgets, because they sit inline in every service call. Meanwhile authentication is bursty, adversarial, and CPU-expensive by design: password hashing must be slow for attackers yet tolerable for users. Reconciling hostile load with 99.99% availability is the core tension of this answer.

Public operating baseline versus design assumptions

Public figures establish the category's scale. Microsoft has publicly described Microsoft Entra ID processing on the order of a billion authentication transactions per day. Okta's public materials report roughly 19,000 customers and billions of monthly authentication transactions across its universal directory. Google's Zanzibar paper describes a global authorization system serving tens of millions of checks per second at peak with p95 latency around ten milliseconds for cached relationships. These are cited company-reported figures, not requirements for our fictional platform.

For capacity planning this answer explicitly assumes: 50 million registered identities, 10,000 tenant organizations, 800 relying-party applications, 16 million interactive logins per day, 120 million token operations per day, 30,000 authorization checks per second average with a 5x peak, and 120 million audit events per day. Unless tied to a citation, every number is a stated assumption, budget, or target.

The invariant set

Three invariants organize the whole design: one principal has exactly one authoritative directory record per tenant; every access decision is explainable from versioned policy and membership evidence; and a revoked credential stops working within a bounded, stated window even though access tokens are stateless.