Architecture

Enmovil has a microservice architecture and employs a data layer to fetch data from the database. The data layer is the single access path between microservices and the MongoDB database. Microservices, external applications, crons, or jobs cannot access database diretly. These have to access database through this layer. This ensures the same security and governance rules apply for every call going to the database.

The following is the data layer architecture of Enmovil

A request goes through three stages:

1. Get a token: The client or microservice authenticates with the Host service. A token is generated.
2. Call with the token: The caller sends requests to the API gateway with the generated token.
3. Data layer checks and runs: The data layer validates the token, the request, enforces policy, runs the operation, and records the outcome.

Components

Enmovil has the following components:

• Clients
• Host
• API Gateway
• Data layer
• Gatekeeper
• Supporting Services
• Data and Oputputs

Clients

The following clients or crons/jobs use the data layer. Three types of login the user login, the system login, and the Service login is allowed. Each client authenticates with an identity suited to it. This is handled automatically by the hosts service.

Caller	Examples	Identity
User interface	Mobile and web applications	User login
Microservices	Node.js and Python services	Service login
External systems	SAP, partner systems, n8n	System login
Crons and jobs	Schedulers, bulk loads	Service login

Host (login)

The Host service authenticates users and service accounts. On success, it issues a token containing:

• user identity
• roles
• tenancy (organization and department)
• expiry time

Callers include this token in every subsequent request. See ----------to add a link--------- for details.

API gateway

The API gateway is the entry point for all traffic. It verifies the token and enforces:

• TLS
• rate limits
• allowed routes

It accepts REST and Kafka traffic and forwards valid requests to the data layer.

Data layer

The data layer processes each request in the order below.

Step	Component	What it does
1	Entry point	Receives requests through the REST API or a Kafka consumer.
2	Token check	Validates the token signature, expiry, user and roles. The data layer repeats this check and doesn't rely on the gateway's.
3	Tenancy resolution	Reads the organization and department from the token. Requests can not override these values.
4	Gatekeeper	Applies access policy
5	Execution	Runs the operation on MongoDB through the models (Mongoose), collections and query engine.

Gatekeeper

The Gatekeeper evaluates each operation against these rules:

• Roles per collection. Which roles may access which collections.
• Field rules. Which fields can be read or written, including how new fields are handled.
• Hidden fields. Fields that are never returned to the caller.
• Tenancy. Applied to every operation.
• Limits and blocked operators. Restrictions on query size and unsafe query operators.

Supporting services

Service	Purpose
Events (outbox)	Writes events together with the data change, so they are delivered after the write and never lost.
Audit	Records who performed which operation, when, and on which rows.
Field registry	Fills a newly added field across all existing records.
Safe retries	Uses idempotency keys and jobs so retried requests aren't applied twice.
Rules admin API	Manages access rules. Rules are versioned, show a warning first and require approval.

Data and outputs

Component	Description
MongoDB	Stores service data and the platform's own collections: _dl_rules (rules), _dl_fields (fields) and _audit (audit trail).
Vault	Supplies configuration to the environment, such as the database address and Kafka credentials.
Events to other services	Receive outbox events for downstream use, such as alerts, mail and reports.

Request flow

1. The client authenticates with the Host service and receives a token.
2. The client sends a request with the token to the API gateway over REST or Kafka.
3. The gateway checks the token, TLS, rate limits and route, then forwards the request.
4. The data layer validates the token again and resolves tenancy from it.
5. The Gatekeeper evaluates roles, field rules and limits. If allowed, the operation runs on MongoDB.
6. The audit record and any outbox events are written, and the response returns to the caller.