Mnemos.
Real-time events, subscriptions, profiles and accounts for Cristalix SAO.
Mnemos application. Actual account home screen from the running product.
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.
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 screenshotWhat 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.
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.
Collect
A separate collector observes supported activity and sends a report through an authenticated connection to realtime-service.
Process
event-service applies the event rules, normalizes the source data and stores the resulting event. Duplicate reports are filtered as part of processing.
Publish
Domain events are delivered through Kafka. The outbox/inbox infrastructure covers retries and repeated message delivery.
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.
Inside the implementation
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.
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.
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.
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.