Our System Series: User Signup. Creating Users, Profiles, and Relationships

Ilya Mikhasik — Fri, 18 Sep 2026 12:09:31 +0000

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.

Our System Series: Architecture Overview

Ilya Mikhasik — Fri, 18 Sep 2026 11:53:44 +0000

Previous: Introduction to Our System Series

Our system uses a four-tier microservices architecture:
Frontend → Application Services → Registry Services → Database

Each tier has a specific responsibility. The frontend handles user interaction, application services implement business and supporting workflows, registry services provide reusable database operations, and the database stores entities and their relationships.

The system uses a graph-like data model consisting of entities and links. Entities can represent users, projects, accounts, or virtually any other type of object required by the application. Links represent relationships between entities.

Instead of creating a separate relationship table for every possible pair of entities, the system uses a general links structure. A link contains the identifiers of the connected entities, its direction, type, weight, and any additional information stored as JSON.

This approach allows us to introduce new entity types and relationships without redesigning the entire database schema. It also provides a flexible foundation for representing complex networks of connected objects.

In the following articles, I will explain the responsibilities of the application and registry services in more detail. I will use the Signup Service as an example to show how the different tiers interact during a typical business workflow.

Next: User Signup

Introduction to Our System Series

Ilya Mikhasik — Fri, 18 Sep 2026 11:50:40 +0000

Over the past few years, I have worked on several backend systems involving microservices, databases, APIs, data protection, service integration. I have often used these technologies as part of my daily work, but using a technology and being able to explain its role clearly are not the same thing.

I am writing this series to take a more structured look at the systems I have been developing and the technologies behind them. Rather than creating a simple list of frameworks and tools, I want to describe how they work together in a real application and why particular design decisions were made.

The series will begin with the architecture itself. I will explain how the system is divided into frontend, application, registry, and database layers, and how responsibilities are distributed between them. I will also discuss the graph-like data model used to represent entities and their relationships, as well as the Registry Factory I developed to automate the creation of CRUD services.

After that, I will describe several typical business scenarios. Each scenario will be supported by service diagrams showing how requests move through the system. I will explain what each service does, how the services communicate, how data is stored, and what happens when a workflow succeeds or fails.

This is also a way for me to take stock of my own experience. Writing about a system forces me to move beyond naming technologies and explain how I used them to solve concrete engineering problems. It helps identify what I understand well, what I need to investigate further, and which parts of my experience are most relevant to future projects.

The articles are not intended to present the architecture as universally correct. Every system reflects its requirements, constraints, and history. My goal is instead to describe the design honestly, explain the decisions in their original context, and reflect on what worked, what was difficult, and what could be improved.

I will begin with an overview of the architecture and then use user registration as the first example of how the different parts of the system work together.

Next: Architecture Overview

DEV Community: Ilya Mikhasik