Messaging Microservice
A shared backend service I proposed and built for internal applications to offer email-like inboxes and chat conversations, with independent read status and message organization for each participant.
At Lotería de Córdoba, different internal applications needed a way for users to exchange messages. I proposed and built one reusable service as the sole engineer, covering the data model, conversation rules, API, and integration design. Each application could then build its own interface on top of the same messaging foundation.
Company project · Confidential
Developed at Lotería de Córdoba. Source code, screenshots, and recordings cannot be shared due to confidentiality.
One Service for Inboxes and Chat
An internal mailbox needs subjects, sent messages, and folders. A chat needs an ongoing conversation between participants. Both need reliable message storage, read status, and rules for who sees each message. I designed a shared backend that supports both interaction styles, keeping those rules consistent across applications.
From Sending a Message to Reading It
The application sends message content and recipient information to the service. A conversation, or thread, groups the related messages. The service decides which conversation to use and maintains each participant's view of it.
- Validate the request and identify the recipients, including the individual recipients represented by a group.
- Create or reuse a conversation according to the application's messaging mode, then save the message and its recipient records.
- Track read status separately for each recipient, so one person reading a message does not mark it as read for everyone else.
- Let each participant organize the conversation independently using favorites, archive, trash, restore, or deletion from their own view.
Two Conversation Patterns
Email-like inboxes
Applications can configure whether a message starts a new conversation or reuses an existing one, supporting messages organized around a subject.
Chat conversations
Messages between a pair of participants reuse a stable conversation, keeping their ongoing exchange together.
Independent State for Each Participant
I separated the shared message content from the records belonging to each recipient. This lets the service deliver the same message to several people while tracking their read status individually.
Conversation organization is also stored per participant. Archiving or removing a conversation from one person's view does not archive or remove it for the other participants. Validation rules keep these state changes consistent.
Internal Messaging in Autogestión (Gmail-like)
Autogestión is Lotería de Córdoba's internal employee web platform. I fully developed its mailbox and integrated it with this service. Employees compose messages with a subject and body, find colleagues by name or unique employee number (legajo), and manage sent messages, favorites, archive, and trash. In this application, trashed messages are deleted after 30 days.
The employee platform supplies the mailbox interface and colleague selection; the messaging service stores conversations and maintains each participant's message state.
Explore the Employee Attendance & Self-Service Platform →Reuse Inside Other Workflows
The same conversation model can support comments attached to a business record. For example, an application for employee objectives could give each objective its own conversation between employee and manager. The application would control who may comment on that objective, while the service would handle the messages and read state.
Integration with Notification Delivery
Messages and alerts have separate responsibilities. The messaging service stores the conversation; a notification service tells users there is something new to read. I implemented that integration after successful message storage, so a notification outage does not prevent the message from being saved. Read-status updates also attempt to synchronize the related notification without blocking the message flow.
Notifications Microservice →Architecture and Delivery
The service is a NestJS API backed by PostgreSQL, with TypeORM for database access. Message creation and recipient records are saved together in a transaction. Background cleanup removes expired trash in batches, using locks to coordinate work across running instances.
I owned the engineering design, implementation, and integration contracts. An external DevOps partner carried out production deployment and account-level configuration in the company's AWS environment, following my technical blueprint and rollout guidance.