Real-Time Messaging System.
Low-latency, encrypted, production-grade chat infrastructure built on MQTT and Google Cloud.
THE
ARCHITECTURE
The system is built on a publish-subscribe model using the MQTT protocol, chosen for its lightweight footprint and low-latency characteristics ideal for mobile chat applications.
A Mosquitto MQTT broker is deployed on Google Compute Engine with a high-availability configuration, serving as the central message routing layer for all client communication.
Mobile clients (Flutter — iOS and Android) connect to the broker over MQTT with TLS on port 8883, ensuring transport-level security for all connections.
Topics are structured as users/{userId}/inbox, enabling direct message delivery to individual user inboxes with clean separation between conversations.
A Python-based microservice deployed on Google Cloud Run acts as the backend API layer, handling message publishing, topic management, and business logic via REST endpoints.
Firebase Authentication is used on the client side to manage user identity and secure access before any broker interaction.
All messages are persisted to Firestore, providing a reliable message history layer decoupled from the broker's transient delivery model.
MQTT was chosen over WebSockets or HTTP long-polling due to its native pub-sub model, minimal protocol overhead, and proven performance in mobile-first, real-time communication scenarios.
Mosquitto was selected as the broker for its lightweight resource footprint, mature TLS support, and straightforward deployment on Compute Engine without managed service overhead.
Cloud Run was used for the microservice layer to keep the backend stateless and auto-scalable, avoiding the cost of always-on compute for API operations.
The topic schema users/{userId}/inbox was deliberately kept flat and user-centric to simplify subscription management on mobile clients and avoid over-engineering topic hierarchies.
Hybrid ECC + AES encryption was chosen for end-to-end security — ECC provides efficient asymmetric key exchange without the overhead of RSA, while AES handles fast symmetric encryption of message payloads, making the scheme both secure and performant on mobile devices.
Firestore was selected as the persistence layer for its real-time sync capabilities, schemaless flexibility, and native integration with the Firebase ecosystem already used for authentication.
Key
Technical Decisions
TECHNICAL
CHALLENGES
01. ECC Key Exchange Between Mobile Clients
The most technically demanding aspect of the project was implementing secure ECC key pair generation and exchange between two Flutter mobile clients. This required designing a flow where each client generates its own ECC key pair, securely shares the public key via the backend, and derives a shared secret to seed AES encryption — all without exposing private keys at any point in the pipeline. Achieving this correctly in Flutter required careful selection of cryptographic libraries and rigorous validation of the key exchange sequence.
02. Broker Security Without a Managed Auth Layer
Integrating Firebase Authentication with Mosquitto required bridging two systems that don't natively communicate. Firebase handles client identity, but Mosquitto has no built-in Firebase plugin. The solution involved enforcing authentication at the Cloud Run API layer and securing broker access through TLS and credential management, creating a layered security model without modifying the broker core.
IMPACT & METRICS