07.02 · Concept
When the User System Breaks
Degrade gracefully when the identity provider, the mail provider or the authorization service is down, instead of logging everybody out.
Graceful degradation for user systems means treating identity, mail and authorisation failures as scoped failure modes, not reasons to evict every user. Existing low-risk sessions may continue briefly from cached state, mail work can queue, and sensitive actions should fail closed with explicit recovery paths.
What this lesson answers
- how to handle identity provider outage safely
- should users be logged out when auth fails
- how to degrade gracefully when email provider is down
Notes
A user system is not one service; it is a chain of dependencies. Login might depend on an identity provider, signup might depend on email delivery, and every request might depend on an authorization service. When one link fails, the goal is not to pretend nothing happened, but to keep safe parts of the product usable and make the broken parts explicit, limited, and recoverable.
The mental model is to classify user-system operations by risk and freshness. Existing sessions can often continue for a bounded time using cached identity and permissions.
References
Common questions
- Should an identity provider outage force every user to log in again?
- No. For many products, that turns a dependency failure into a wider outage. A safer approach is bounded trust: keep recently validated sessions working for low-risk actions, apply clear expiry rules, and block operations that require fresh identity proof or elevated confidence.
- What should happen when the mail provider is unavailable?
- Mail-dependent work should usually be queued rather than dropped. Signup verification, password reset messages and notifications can wait until delivery recovers, while the product clearly tells users which actions are pending. Security-sensitive flows still need expiry and replay protection.
- How should authorisation behave when the authorisation service is down?
- Authorisation needs a risk-based policy. Low-risk reads may use recent cached permissions for a limited time, while privilege changes, admin actions and high-impact writes should fail closed. The important part is to encode those rules explicitly, not leave behaviour to retries and timeouts.