developer/galaxy-game
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

feat: user service

Browse Source
This commit is contained in:
Ilia Denisov
2026-04-10 19:05:02 +02:00
committed by GitHub
parent 710bad712e
commit 23ffcb7535
140 changed files with 33418 additions and 952 deletions
Download Patch File Download Diff File Expand all files Collapse all files
ARCHITECTURE.md
+30 -8
View File
@@ -43,7 +43,9 @@ The current v1 platform uses Redis as the main data store and Redis Streams as t
* The platform exposes a single external entry point: **Edge Gateway**.
* Public unauthenticated flows use REST/JSON.
* Authenticated user traffic uses signed gRPC over HTTP/2 with protobuf control envelopes and FlatBuffers payload bytes.
* Authenticated user edge traffic uses signed gRPC over HTTP/2 with protobuf control envelopes and FlatBuffers payload bytes.
* Trusted synchronous inter-service traffic uses REST/JSON unless a service-specific contract states otherwise.
* For the direct `Gateway -> User` self-service boundary, gateway keeps the external authenticated gRPC + FlatBuffers contract and performs REST/JSON transcoding toward `User Service` internally.
* The gateway handles only edge concerns: parsing, authentication, integrity checks, anti-replay, rate limiting, routing, and push delivery. Business authorization and domain rules remain in downstream services.
* `Auth / Session Service` is the source of truth for `device_session`, but it is not on the hot path of every authenticated request. Gateway authenticates steady-state traffic from session cache and lifecycle updates.
* `Game Lobby` owns platform-level metadata of game sessions.
@@ -65,6 +67,10 @@ The gateway already distinguishes:
* public REST/JSON for unauthenticated traffic such as health checks and public auth;
* authenticated gRPC over HTTP/2 for verified commands and push delivery.
For downstream business services, the current default trusted transport is
strict REST/JSON. Gateway may therefore authenticate and verify one external
FlatBuffers command, then transcode it to one trusted downstream REST call.
The public auth contract is:
* `send-email-code(email) -> challenge_id`
@@ -230,17 +236,22 @@ Direct integrations:
## 3. [User Service](user/README.md)
`User Service` owns user identity and profile as platform-level business data.
`User Service` owns regular-user identity and profile as platform-level
business data.
It is the source of truth for:
* `user_id`;
* profile fields and editable user settings;
* role model, including admin role;
* `user_id` of regular platform users;
* regular-user profile fields and editable user settings;
* current tariff/entitlement state;
* user-specific limits and platform sanctions;
* latest effective `declared_country`.
System-administrator identity remains outside this service and belongs to the
later `Admin Service`. Trusted administrative reads and mutations against
regular-user state do not make `User Service` the owner of administrator
identity.
It is directly reachable through gateway for selected user-facing operations such as:
* reading and editing allowed profile fields;
@@ -253,6 +264,17 @@ Not every profile mutation goes directly here. For example:
* email change must use a code-confirm flow;
* `declared_country` change remains under admin approval flow via `Geo Profile Service`.
Architectural rules fixed for this service:
* `User Service` owns regular-user identity only; system-admin identity is out
of scope.
* `User Service` stores only the current effective `declared_country`; review
workflow and history belong to `Geo Profile Service`.
* During the current auth-registration rollout, `Auth / Session Service`
passes temporary `preferred_language="en"` plus the confirmed `time_zone`
into `User Service`. Gateway-side geoip language derivation is a later
rollout step and is not part of the current source-of-truth contract.
Future billing does not become a direct dependency of other services. `Billing Service` will feed entitlement/payment outcomes into `User Service`, and the rest of the platform will continue to use `User Service` as the source of truth for current entitlements.
## 4. Mail Service
@@ -533,7 +555,7 @@ flowchart TD
N["Notification Service"]
M["Mail Service"]
U -->|"users, roles, tariffs, limits, sanctions, current declared_country"| X1["Platform user identity"]
U -->|"regular users, profile/settings, tariffs, limits, sanctions, current declared_country"| X1["Platform user identity"]
A -->|"challenges, device sessions, revoke/block state"| X2["Auth/session state"]
L -->|"game metadata, invites, applications, membership, roster"| X3["Platform game records"]
G -->|"runtime state, current turn, engine health, engine mapping, engine version registry"| X4["Running-game state"]
@@ -918,8 +940,8 @@ Recommended order for implementation is:
2. **Auth / Session Service** (implemented)
Public auth flow, `device_session`, revoke/block lifecycle, gateway session projection.
3. **User Service** (planned)
Platform user identity, roles, tariffs/entitlements, user limits, settings, sanctions, and current `declared_country`.
3. **User Service** (implemented)
Regular-user identity, profile/settings, tariffs/entitlements, user limits, sanctions, and current `declared_country`.
4. **Mail Service**
Internal email delivery for auth codes first, later for platform notifications.