07.01 · Lecture · Free
The Architecture of a User System
Lay out identity, authorization, profile, notification and support as separate components with named boundaries, and say which of them you should not build yourself.
Curated for this lesson1/2
Building the User System
AWS re:Invent 2022 - SaaS microservices deep dive: Simplifying multi-tenant development (SAS405)
Microservices and multi-tenancy framing fits decomposing identity, authorization, profiles, notifications, and support into separate components.
A user system is a set of separate components: identity, authorization, profile, notifications and support. Identity and low-level message delivery are usually provider-owned; profile is product-owned; authorization needs an explicit policy boundary; support needs audited, limited privilege. Treating all of this as one users table creates security and operational risk.
What this lesson answers
- how to split a user system architecture
- what parts of user management not to build
- identity versus authorization versus profile boundaries
Notes
A user system is not one feature called “users”; it is a cluster of related but different responsibilities. Identity answers “who is this actor?” Authorization answers “what may this actor do?” Profile stores application-specific information about the person or account. Notifications deliver messages through email, SMS, push, or in-app channels. Support covers account recovery, impersonation controls, audit trails, customer-service tooling, and escalation workflows. These pieces interact, but they should not be treated as one database table and a few helper functions.
A useful mental model is to draw named boundaries around trust and ownership. Identity is a security boundary and should usually be delegated to a mature provider such as Auth0, Cognito, Okta, Entra ID, Clerk, or a similar managed identity platform. Authorization may be partly in your app, but should have an explicit policy model rather than scattered if-statements. Profiles belong to your product domain and are safe to build yourself. Notifications should usually use specialized delivery providers rather than raw SMTP or carrier integrations. Support tooling often combines internal admin UI, ticketing systems, audit logs, and carefully limited privileged actions.
The common misconception is that “user management” means login plus a users table. That is wrong because login is only one slice of the system, and it is the slice with the most security, compliance, abuse, and operational risk. Password storage, MFA, account recovery, session handling, OAuth, SAML, breach response, deliverability, unsubscribe rules, auditability, and support impersonation are all separate concerns with different failure modes. Collapsing them together makes it hard to reason about access, hard to test, and dangerous to operate.
After this lesson, you should be able to sketch a user-system architecture with clear boxes and contracts: an identity provider issues tokens, an authorization service or library evaluates permissions, your application owns profile data, a notification service sends messages, and support tools operate through audited, least-privilege workflows. You should also be able to say what not to build yourself: password authentication, MFA, federated login, low-level email/SMS delivery, and ad hoc privileged support access unless you have a strong reason and the operational maturity to own them.
Common questions
- Is a users table enough for a production user system?
- No. A users table can hold product data, but it should not become the place where login, permissions, recovery, notifications and support behaviour are all improvised. Those concerns have different owners, risks and failure modes. Keeping them separate makes access decisions clearer and operations safer.
- Which parts of user management should usually be outsourced?
- Password authentication, MFA, federated login and session handling should usually sit with a managed identity provider. Raw email and SMS delivery should usually use specialist providers too. These areas carry security, abuse, compliance and operational burdens that most product teams should not own directly.
- Where should authorization live in a user system?
- Authorization can live inside the application or in a dedicated service or library, but it needs a named policy model. The important point is that permission checks are not scattered across random handlers as informal conditionals. There should be one clear way to ask what an actor may do.
Short definition: what is Architecture of a User System?