Home / Guides / Real-Time Chat & Messaging App

Event-driven microservices

How to Architect a Real-Time Chat & Messaging App

Architecting a real-time chat & messaging app requires a robust event-driven system to handle high message throughput and low latency. This blueprint leverages WebSockets for instant communication, a scalable backend for message persistence and delivery, and dedicated services for media and user presence.

Recommended architecture pattern

Recommended tech stack

Frontend

React Native / React (Web) + Redux-Saga: Provides a unified codebase for mobile/web and efficient UI rendering for real-time updates with robust state management.

Backend

Node.js (with Fastify/Express) + TypeScript: Excellent for I/O-bound operations like WebSockets, enabling high concurrency with a single-threaded event loop and type safety.

Database

PostgreSQL (for core data) + Apache Cassandra (for message history): PostgreSQL for relational user/group data with ACID properties; Cassandra for highly scalable, eventually consistent message storage with fast writes.

Real-time / Messaging

Apache Kafka + WebSockets (native or Socket.IO): Kafka for reliable, high-throughput message queuing and stream processing; WebSockets for persistent, low-latency client-server communication.

Infrastructure

Kubernetes (EKS/GKE/AKS): Orchestrates microservices, provides auto-scaling, service discovery, and load balancing crucial for high availability and elastic scaling.

Authentication

Auth0 / Firebase Auth: Managed service for secure user authentication (OAuth2/OIDC, JWTs), reducing development overhead and ensuring compliance.

Key third-party services

AWS S3 (Media Storage) + Cloudinary (Media Processing) + Twilio (SMS/Voice fallback) + Stripe (Payments): S3 for scalable object storage; Cloudinary for media optimization; Twilio for out-of-app notifications; Stripe for secure payment processing for premium features.

Core components

Key data model

Entity	Key fields	Notes
User	id, username, email, password_hash, profile_picture_url, status	Indexed on id (PK), username, email. Stores user profile information.
ChatSession	id, type (private, group), name (for groups), created_at, last_message_id	Indexed on id (PK), type. Represents a conversation thread.
ChatParticipant	chat_session_id, user_id, joined_at, last_read_message_id, role	Composite primary key (chat_session_id, user_id). Tracks user involvement in chats.
Message	id, chat_session_id, sender_id, content, type (text, image, video), timestamp, media_url	Primary key (chat_session_id, timestamp, id) in Cassandra for efficient time-series queries. Content can be encrypted.
Contact	user_id, contact_user_id, status (pending, accepted, blocked)	Composite primary key (user_id, contact_user_id). Manages user connections.
MediaFile	id, message_id, uploader_id, original_url, processed_url, file_type, size	Indexed on id (PK), message_id. Stores metadata for uploaded files.

Core API endpoints

Method	Endpoint	Purpose
POST	/auth/register	Register a new user account.
POST	/auth/login	Authenticate user and issue JWT for subsequent API calls.
GET	/users/{id}/profile	Retrieve a specific user's public profile information.
POST	/chats/private	Create a new 1-to-1 private chat session between two users.
GET	/chats/{id}/messages	Retrieve paginated message history for a given chat session.
POST	/chats/{id}/messages	Send a new message to a chat session (used as a fallback or for non-realtime messages).
POST	/media/upload	Upload a media file (image, video) to storage, returning a temporary access URL.
GET	/users/me/chats	Get a list of all chat sessions the authenticated user is a part of.
PUT	/users/me/status	Update the authenticated user's online presence status (e.g., 'online', 'away').
WS	/ws/chat	WebSocket endpoint for real-time messaging, presence updates, and typing indicators.

Scaling considerations

• High Message Throughput: Utilize Apache Kafka as a message broker to decouple message producers from consumers, allowing asynchronous processing and buffering of millions of messages per second.
• Real-time Connection Management: Employ a cluster of horizontally scalable WebSocket servers (e.g., Node.js instances) behind a load balancer to handle millions of concurrent persistent client connections.
• Message History Retrieval: Partition message data in Cassandra by `chat_session_id` and `timestamp` to ensure fast, concurrent reads and writes for specific chat histories without bottlenecking.
• User Presence Updates: Leverage Redis Pub/Sub for broadcasting presence changes (online/offline, typing) across WebSocket servers efficiently, minimizing database load and ensuring low latency.
• Media Storage & Delivery: Use AWS S3 for durable, scalable object storage and integrate a CDN (e.g., CloudFront) for global caching and high-speed delivery of media files, reducing backend load.
• Database Hotspots: Implement database sharding for PostgreSQL (e.g., by user ID or chat ID ranges) to distribute read/write load and improve query performance for user and chat metadata.

Security & compliance

• GDPR/CCPA (Data Privacy): Implement robust data minimization practices, encryption at rest and in transit (TLS/SSL), user consent mechanisms for data processing, and clear data retention policies with user data deletion capabilities.
• OWASP Top 10 (Application Security): Conduct regular security audits, enforce strict input validation, implement rate limiting on API endpoints, use secure authentication (JWTs, OAuth2), and protect against common vulnerabilities like XSS, CSRF, and SQL injection.
• Media Content Moderation: Integrate AI-based content moderation services (e.g., AWS Rekognition, Google Vision AI) for uploaded images and videos to detect and flag inappropriate, illegal, or harmful content, ensuring platform compliance.
• End-to-End Encryption (Optional but Recommended): Offer client-side encryption for sensitive messages (e.g., using the Signal Protocol) to ensure only sender and recipient can read content, requiring careful key management and client-side implementation.

Estimated monthly cost

Want a tailored build estimate? Try the free software cost estimator or the tech stack finder.

Suggested build plan

Phase	Timeframe	Deliverables
Phase 1: Core Real-time Messaging	Weeks 1-6	User registration/login, 1-to-1 text chat, basic WebSocket connectivity, message persistence, user profiles.
Phase 2: Group Chats & Media	Weeks 7-12	Group chat functionality, media upload/display (images/videos), message notifications, presence indicators (online/offline).
Phase 3: Scalability & Reliability	Weeks 13-20	Kafka for message queuing, Cassandra for message history, Kubernetes deployment, monitoring & alerting, basic analytics.
Phase 4: Advanced Features & Polish	Weeks 21-28	Message search, read receipts, typing indicators, end-to-end encryption (optional), UI/UX refinement, security hardening, moderation tools.

Frequently asked questions

Why not just use a single relational database for messages?

A single relational database would struggle with the immense write throughput and historical message retrieval at scale required by a chat app. Cassandra (a NoSQL database) provides superior performance for time-series data like messages due to its distributed nature and optimized write path.

How do you handle offline messages and ensure they are delivered?

Messages are queued in Kafka and persisted to Cassandra. When an offline user reconnects, the Notification Service retrieves unread messages from Cassandra and pushes them via WebSocket. For mobile users, push notifications are sent via FCM/APNS to alert them of new messages.

What about voice and video call functionality?

For voice/video, integrate WebRTC. This typically involves a separate Signaling Service (using WebSockets) to negotiate connections, and STUN/TURN servers for NAT traversal. A dedicated media server (e.g., Kurento, Jitsi Videobridge) would be needed for multi-party conferencing.

How do you ensure message delivery order for a chat session?

Kafka guarantees message order within a partition. By routing all messages for a specific chat session to the same Kafka partition, and ensuring WebSocket clients process messages sequentially, delivery order is maintained. Client-side sequence numbers can also provide additional guarantees.

Is end-to-end encryption feasible for group chats, and how is it implemented?

Yes, but it's significantly more complex than 1-to-1. Protocols like the Signal Protocol extend to group messaging using 'double ratchet' algorithms for forward secrecy and deniability. This requires careful client-side implementation for key management and message encryption, as the server should not have access to message content.

Related guides