01 / Real-time services · independent product

Mnemos.

Real-time events, subscriptions, profiles and accounts for Cristalix SAO.

RoleIndependent developer
StatusActive product
In briefApproximately 150 users
M. MNEMOS / ACCOUNT HOME
EVENTS · ACCOUNTS · REALTIME Mnemos ~150 people using the platform
Real Mnemos application account home: active events, daily rewards, wallet, roles, teams and activity
KOTLIN / KAFKA / REACTAPPLICATION INTERFACE

Mnemos application. Actual account home screen from the running product.

About the project

Realtime events and everything around them

Mnemos started as a way to follow events in Cristalix SAO without constantly checking the game. It developed into a platform with live events, subscriptions, player profiles, teams, notifications, rewards and account management.

I designed and implemented the backend, web application and deployment setup. Around 150 people have used Mnemos; the product has also had paid features. Development continues as I improve the individual services and user experience.

Actual Mnemos home screen showing account, live events, rewards, wallet, team and activity
Product interface

Account home

This screen brings together the active account, global events, daily rewards, wallet balance, team members and recent activity. Those sections are backed by different parts of the Mnemos platform.

View full screenshot
My contribution

What I worked on

  • Kotlin/Spring Boot services, service-to-service contracts and Kafka messaging.
  • Account and permissions flows, Keycloak authentication and realtime sessions.
  • React/TypeScript frontend, Telegram integration, deployment and diagnostics.
A closer look

From a game event to a notification

The event pipeline is one of the central parts of Mnemos. The platform has to show an event as it happens, update the feed and apply each user’s notification settings. Repeated reports must not turn into duplicate notifications.

01

Collect

A separate collector observes supported activity and sends a report through an authenticated connection to realtime-service.

02

Process

event-service applies the event rules, normalizes the source data and stores the resulting event. Duplicate reports are filtered as part of processing.

03

Publish

Domain events are delivered through Kafka. The outbox/inbox infrastructure covers retries and repeated message delivery.

04

Notify

The realtime layer updates connected clients. notification-service checks saved subscriptions and hands eligible messages to the Telegram integration.

The same event can feed several parts of the product without the collector knowing about profiles, subscriptions or Telegram.

Implementation details

Inside the implementation

01

Service boundaries

The backend is split around product responsibilities: accounts, events, notifications, player directory, profiles, wallet, social features and realtime transport. Each service owns its business logic and contracts. HTTP is used for synchronous operations; Kafka carries changes that other domains need to react to.

Shared libraries contain messaging, authentication and infrastructure code rather than a shared domain model. This keeps common mechanisms reusable without forcing unrelated services into one dependency graph.

02

Reliable event processing

Publishing an event and updating a database cannot be treated as two unrelated operations. Mnemos uses a transactional outbox for outgoing events and inbox/deduplication for consumers. A retry can happen without creating a second logical event in every downstream service.

Realtime delivery is separate from durable processing: WebSocket clients receive updates quickly, while the event and notification services remain responsible for persistent state.

03

Integrations and operational constraints

The player directory resolves identities, tracks presence and projects the current SAO realm. Its integration with the upstream API has quota and cooldown handling, separate request lanes and metrics for stale observations and queue pressure.

Some scheduled work intentionally runs in a single replica while its rate limits are process-local. That is a documented constraint of the current implementation, not something hidden behind a “scalable” label.

Technologies
KotlinSpring BootApache KafkaPostgreSQLRedisKeycloakReact
Outcome

Where it stands

Mnemos is an independently built product that people actually use, with functionality extending well beyond its original event feed. I maintain the codebase, deploy changes and handle failures and regressions.

The account screen brings together features backed by different services: live events, the account, the wallet, team membership and recent activity.

Next projectWaveCode