Architecture of a User System
Architecture of a user system is the decomposition of user-related capabilities into explicit components: identity, authorisation, profile, notifications, and support. It treats login, permissions, product data, messaging, and privileged operations as separate responsibilities with different trust boundaries, owners, failure modes, and build-versus-buy decisions.
The reason this architecture exists is that “users” is not a single feature. A login form and a users table quickly grow into password handling, sessions, federation, permission checks, profile fields, email delivery, account recovery, admin actions, audit trails, and customer support workflows. If those concerns are mixed together, security rules become implicit, support staff gain unsafe powers, and engineers cannot tell whether a bug is about identity, access, product state, or messaging.
A practical design draws named boxes around each responsibility. An identity provider authenticates the actor and issues tokens. An authorisation layer evaluates whether that actor can perform a requested action, using roles, relationships, attributes, or policies. The application owns profile data because it is product-specific. A notification component sends messages through delivery providers. Support tooling performs account recovery, investigation, or impersonation through narrowly scoped, logged operations rather than direct database edits.
The trade-off is more boundaries to design and maintain. You need contracts between components, token formats, user identifiers, event flows, and clear ownership of data. Managed providers reduce security and operational burden, but introduce integration work, cost, vendor behaviour, and migration risk. Building everything yourself can feel simpler early on, but the expensive parts are not the screens; they are abuse handling, recovery, auditability, deliverability, and correctness under failure.
Engineers meet this architecture when adding sign-up, single sign-on, role checks, organisation membership, user preferences, transactional email, admin consoles, or support access. The common mistake is to call all of that “user management” and put it behind one service or table. In practice, identity, low-level message delivery, and dangerous support powers are usually things to delegate or heavily constrain, while profile data and product-specific permission logic often remain inside your system.
Common questions
- What is the difference between identity and authorisation?
- Identity proves who the actor is, usually by authenticating credentials, sessions, or federated login and producing a token or principal. Authorisation decides what that actor may do in a particular context. Confusing them leads to code that treats being logged in as permission, which is rarely correct for real products.
- Which parts of a user system should not usually be built in-house?
- Password authentication, multi-factor authentication, federated login, account recovery primitives, and raw email or SMS delivery are usually poor candidates for custom implementation. They carry security, abuse, compliance, and operational burdens that specialised providers are built to handle. Your own engineering effort is usually better spent on product-specific profiles, permissions, and workflows.
- Should authorisation be a separate service?
- It depends on scale, team structure, and how many applications need the same policy decisions. The important part is not always a network service; it is having an explicit policy model with testable rules. Small systems may use a library. Larger systems often benefit from a central authorisation component or shared policy engine.
- Why is support part of the user-system architecture?
- Support staff often need privileged actions: helping with recovery, viewing account state, triggering messages, or investigating access issues. Those powers must be designed, not improvised. Good support architecture uses least privilege, approval where needed, clear audit logs, and safe tooling instead of giving people broad database or admin access.