Previous: Architecture Overview
In the previous article, I introduced the four-tier architecture used by our system and described its graph-like data model. This article shows how those ideas come together in a practical business workflow: user registration.
User registration is not limited to creating a single database record. The workflow creates a user, associates that user with a project and an account, creates a profile, associates the profile with the project, and triggers a signup email.
The Signup Service coordinates the workflow, while the User Profiles Service and User Profiles Registries handle user-related data operations.
The complete interaction is shown in the accompanying diagrams:
- User signup, part 1.
- User signup, part 2.
Separating users and profiles
The system separates user and profile entries because they contain different categories of information.
A user entry contains system identity and authentication-related information. It includes the user ID, user type, registration date, login, last-login timestamp, account-status flags, and the profile_id of the associated profile.
A profile entry contains personal and project-related information. It includes the profile ID, profile type, first and last names, birth date, sex, contact phone numbers, contact email addresses, main photo, project ID, and additional information such as education, specialty, registration address, and personal-data consent.
The user entry references the profile through profile_id. In the usual case, user_id and profile_id have the same value. This makes it easy to correlate the two records while keeping their responsibilities separate.
This separation establishes a clear boundary between:
Authentication and system identity.
Personal and user-facing information.
Account and project relationships.
Access control and profile management.
Authentication-related operations can work with the user entry without loading the full profile. Profile-related operations can work with personal data without exposing authentication-specific fields such as login status or password-management flags.
The user and profile are separate registry entries, but the profile_id field provides their direct association. Other relationships, such as the user’s association with an account or project, are represented through link records.
Registration flow
The registration process is divided into two stages:
- Creating the user and establishing the user’s relationships.
- Creating the profile and triggering the signup email.
The client sends the registration request to the Signup Service. The request contains user and profile data, together with Project-ID and Account-ID headers that provide the context for the new registration.
The Signup Service coordinates the process but does not directly access the database. It delegates user and profile operations to the User Profiles Service.
Creating the user
The User Profiles Service receives the request to create a user and encrypts the relevant data before persistence.
It then asks User Profiles Registries to create a user entry. The registry service inserts the record into the users table and returns the result.
The user entry contains system and authentication-related data, including:
- User ID
- User type
- Registration date
- Login
- Last-login timestamp
- Account-status flags
- Associated profile ID
After the user entry has been created, the User Profiles Service creates two relationships:
- A project-user link
- An account-user link
These links associate the new user with the project and account identified by the request headers.
The relationships are stored as link records rather than as separate relationship tables. This is an example of the graph-like data model introduced in the architecture overview.
Creating the profile
After the user has been created successfully, the Signup Service asks the User Profiles Service to create the profile.
The User Profiles Service encrypts the relevant profile data and requests a profile entry from User Profiles Registries. The registry service stores the entry in the profiles table.
The profile entry contains personal and project-related data, including:
- Profile ID and profile type
- First name and last name
- Birth date and sex
- Contact phone numbers
- Contact email addresses
- Main profile photo
- Additional information such as education, specialty, registration address, and personal-data consent
The profile receives the identifier referenced by the user’s profile_id. In the usual case, the user ID and profile ID are the same UUID, which provides a simple one-to-one association between the two records.
The User Profiles Service then creates a project-profile link, associating the profile with the project supplied during registration.
At this point, the database contains:
- A user entry containing system and authentication information
- A profile entry containing personal information
- An account-user link
- A project-user link
- A project-profile link
After these operations succeed, the Signup Service returns the user ID and profile ID to the client.
Signup email event
Once the user and profile records have been created, the Signup Service sends a signup email event to the Event Processor.
The Event Processor processes the event and sends the signup email to the user.
Separating email delivery from the registration workflow keeps the Signup Service focused on creating the required entities and relationships. Email processing can be handled independently by the Event Processor rather than being implemented as part of the main registration logic.
This separation also creates the possibility of handling email-specific concerns independently, such as retries, provider integration, and delivery monitoring. The exact behavior depends on the event-processing implementation.
Design considerations
This workflow illustrates several architectural decisions:
- User identity and personal profile data are stored separately
- The user entry references its profile through profile_id
- The same UUID is usually used for both the user and profile identifiers
- Account and project relationships are represented as reusable link records
- Application services coordinate business workflows
- Registry services provide generic database operations
- Protected data is encrypted before persistence
- Email delivery is delegated to a separate event-processing component
The goal is to keep responsibilities explicit. The Signup Service does not need to know how every table is implemented, and the registry service does not need to understand the complete business meaning of registration. Each component performs a focused part of the overall workflow.
Closing perspective
User signup demonstrates how the system’s architecture and data model work together in a real business scenario.
A single registration creates several related records, but the process remains organized because each service has a defined responsibility. The Signup Service coordinates the workflow, the User Profiles Service manages user-related operations, the registry layer handles reusable persistence, and the Event Processor handles post-registration communication.
The separation between users and profiles is particularly important. Authentication and system identity are kept in the user registry, while personal and project-related information is kept in the profile registry. The profile_id field connects the two records, and the shared identifier convention makes the relationship straightforward to resolve.
The next article will focus on registries: what they are, why they were introduced, and how the Registry Factory reduces the amount of repetitive CRUD code required when adding new entity types.
Top comments (0)