
FIeldChat
FieldChat is a real-time team messaging application built to explore the engineering challenges behind persistent WebSocket connections, distributed state, caching, and scalable message delivery.
The application provides a chat experience where users can communicate through real-time connections while the backend manages conversations, messages, authentication, notifications, and shared state across connected clients. The backend is built with FastAPI, WebSockets, PostgreSQL, and Redis, with the application containerized using Docker for deployment.
The primary goal of the project was to go beyond building a basic chat application and understand how real-time systems behave when multiple clients, persistent connections, caching, and concurrent events are involved.
Industry
Developer Tools / Communication & Collaboration
Client
Self
Timeline
August 2026 to Present
Live Product
Visit WebsiteThe Problem
This project was primarily learning-driven rather than problem-driven. I wanted to understand what actually happens behind real-time applications and how systems need to be designed when communication is no longer based entirely on traditional request-response APIs.
The main areas I wanted to explore were:
How persistent WebSocket connections can be managed reliably.
How state can be shared when multiple clients are connected simultaneously.
How frequently accessing the database for every real-time event affects the architecture.
How Redis can be used as a fast shared layer for real-time application state.
How to keep cached state synchronized with the persistent database.
How a real-time backend behaves when deployed as an actual production service rather than running only in local development.
The Challenge
Building FieldChat involved challenges across both the user experience and the underlying real-time architecture. Managing multiple active sessions across different devices required keeping track of connected clients and ensuring that actions performed on one device were reflected consistently across the others.
Maintaining reliable, long-lived WebSocket connections was another challenge, particularly while handling frequent events such as new messages, delivery and read-state updates, reactions, replies, message deletion, and in-app notifications.
Another important challenge was maintaining shared real-time state without querying the database for every WebSocket event. With multiple devices and conversations interacting simultaneously, repeatedly hitting the database could introduce unnecessary load and latency. This led to using Redis as a shared caching and synchronization layer, with cache management and periodic snapshot synchronization used to balance real-time performance with persistent data consistency.
Supporting both DMs and groups also introduced additional state-management considerations, especially around delivering the right events to the right connected sessions and keeping message states consistent across participants.
Finally, deploying the complete system on Oracle Cloud Infrastructure (OCI) was challenging because the production environment introduced additional concerns around service configuration, networking, persistent storage, environment variables, database migrations, Redis, and maintaining WebSocket connectivity outside the local development environment.
The Solution
FieldChat uses a combination of FastAPI, WebSockets, PostgreSQL, Redis, and Docker to build the real-time messaging architecture.
WebSockets are used for persistent communication between clients and the server, allowing events such as messages, reactions, replies, delivery/read updates, deletions, and notifications to be propagated in real time. A session-based multi-device system keeps track of a user's active devices so that events can be synchronized across their connected sessions.
PostgreSQL acts as the persistent source of truth for application data, while Redis is used as a fast shared layer for real-time state and caching. Instead of performing a database query for every incoming message or WebSocket event, frequently accessed conversation state can be handled through the cache-management layer. Cached data is synchronized with persistent storage through snapshots, reducing unnecessary database operations while retaining durable data in PostgreSQL.
The messaging layer supports both one-to-one and group conversations, along with delivery and read states, message replies, reactions, message deletion for either the individual user or everyone in a conversation, and in-app notifications.
The frontend also supports common messaging-app functionality such as multiple theme modes and rich-text message composition, allowing messages to contain formatting and other standard rich-text editing capabilities.
The application is containerized with Docker, with the backend, database, Redis, and migration workflow configured as deployable services. This made it possible to reproduce the same multi-service architecture locally and in the OCI deployment environment.
Summary
FieldChat was built as a hands-on exploration of real-time system architecture and scalable backend design.
The project gave me practical experience building persistent WebSocket communication, managing multi-device sessions, synchronizing real-time events, implementing delivery and read states, handling DM and group conversations, and designing features such as replies, reactions, message deletion, notifications, and rich-text messaging.
From an infrastructure perspective, the project helped me understand the trade-offs between real-time performance, database persistence, caching, and consistency. Using Redis as a shared caching layer and synchronizing it with PostgreSQL provided practical experience in reducing unnecessary database operations while keeping application state coordinated across devices.
Deploying the complete system to Oracle Cloud Infrastructure also gave me experience with running a multi-service, containerized real-time application outside a local development environment.
Overall, FieldChat was less about recreating an existing messaging product and more about learning how the systems behind real-time applications are designed, connected, and operated in practice.