How tanvir-art/kafka_whatsapp_clone works
1. Repository shape
- This is a microservices-based WhatsApp clone split into four runnable Node.js services plus local infrastructure.
- The services are: API Gateway, Auth Service, Chat Service, and Socket Gateway.
- Supporting infrastructure is MongoDB for persistence, Kafka for async events, and Redis for presence/state.
2. System boundary and entry points
- The API Gateway is the main HTTP entry point for the frontend/client.
- It exposes the public /api/auth and /api/chat routes, then proxies requests to the internal auth and chat services.
- The Socket Gateway is a separate real-time entry point for Socket.IO clients.
3. API Gateway responsibilities
- The gateway owns cross-cutting concerns: authentication middleware, rate limiting, request forwarding, and centralized logging.
- It does not implement business logic itself; instead it delegates to authProxy and chatProxy.
- Architecturally, it is the trust boundary between external clients and internal services.
4. Auth Service subsystem
- The auth service is organized in a classic layered shape: route → controller → service → model → DB/config.
- It handles registration, login, and refresh-token flow.
- JWT logic and password hashing live in service-local utilities, which indicates auth is self-contained and not dependent on the gateway for token creation/verification.
5. Chat Service subsystem
- The chat service owns the core chat domain: messages and groups.
- It also follows a route/controller/service/model split, with separate controllers for groups and messages.
- This service is responsible for persisting chat data in MongoDB and emitting message-related events to Kafka.
6. Async event flow via Kafka
- The key asynchronous path is: chat service writes message data → publishes Kafka event → socket gateway consumes event.
- The Kafka producer lives in the chat service under the message event module.
- The Kafka consumer lives in the socket gateway, which turns backend events into client-facing Socket.IO updates.
7. Socket Gateway responsibilities
- The socket gateway is the real-time delivery layer, separate from REST APIs.
- It hosts the Socket.IO server, listens to Kafka message events, and emits socket events to connected clients.
- It also has a presence service backed by Redis, so online/offline state is not tied to a single process instance.
8. Redis usage
- Redis is used by the socket gateway for presence tracking.
- This keeps ephemeral connection state out of MongoDB and supports fast reads/writes for online user status.
- Redis is part of the real-time subsystem, not the durable data layer.
9. Data persistence model
- MongoDB is the durable store for both auth and chat domains.
- Auth service stores user/auth records.
- Chat service stores chat-specific domain entities such as messages, conversations, and groups.
10. Runtime and deployment boundaries
- Each service has its own package.json, src, and server.js, so they are independently deployable processes.
- docker-compose.yml provides the local infrastructure layer for MongoDB, Redis, and Kafka.
- The repo is designed for local multi-process development rather than a monolith.
11. External client flow
- A browser/client first authenticates through the API Gateway.
- Protected chat requests go through the gateway with a JWT bearer token.
- Real-time UI features connect directly to the Socket Gateway with an access token for Socket.IO auth.
12. How to draw the architecture
- Draw the frontend/client at the edge, then the API Gateway as the HTTP ingress.
- Place Auth Service and Chat Service behind the gateway as separate HTTP microservices.
- Place MongoDB under auth/chat, Kafka between chat and socket, and Redis under socket.
- Show the Socket Gateway as a parallel ingress for real-time connections, consuming Kafka and emitting Socket.IO events outward.
Main entry points: app.js API App · auth.service.js Auth Service · message.service.js Chat Service · socket.server.js Socket Server
Components 23
Edge
External clients and ingress layers
- Client · Frontend or mobile client
- API App · Main HTTP ingress and trust boundary
api-gateway/src/app.js - Auth MW · JWT-bearing request authentication
api-gateway/src/middleware/authMiddleware.js - Rate Limit · Per-request throttling
api-gateway/src/middleware/rateLimit.js - Auth Proxy · Forwards auth routes to auth service
api-gateway/src/services/authProxy.js - Chat Proxy · Forwards chat routes to chat service
api-gateway/src/services/chatProxy.js
Auth Service
Registration, login, and token flow
- Auth Route · Registration, login, refresh endpoints
auth-service/src/app/module/auth.route.js - Auth Controller · HTTP handling for auth flows
auth-service/src/app/module/auth.controller.js - Auth Service · Token and credential logic
auth-service/src/app/module/auth.service.js - Auth Model · User and auth records
auth-service/src/app/module/auth.model.js - Auth DB · Auth database connection
auth-service/src/app/config/db.js
Chat Service
Chat domain and async event publishing
- Chat Routes · Message and group endpoints
chat-service/src/routes/message.routes.js - Chat Controllers · Group and message request handlers
chat-service/src/module/controllers/message.controller.js - Chat Service · Chat rules and persistence orchestration
chat-service/src/module/services/message.service.js - Message Event · Publishes message events
chat-service/src/module/events/message.producer.js - Chat DB · Chat database connection
chat-service/src/config/db.js
Realtime
Socket.IO delivery and presence state
- Socket Server · Realtime connection entry point
socket-gateway/src/socket/socket.server.js - Event Consumer · Consumes chat events for delivery
socket-gateway/src/consumers/message.consumer.js - Presence Service · Online status and connection state
socket-gateway/src/services/presence.service.js - Socket Events · Emits client-facing socket updates
socket-gateway/src/socket/socket.events.js
Connections 25
- Client → API App: HTTP API · Client sends REST requests to the gateway
- Client → Socket Server: Socket.IO · Client connects directly for realtime features
- API App → Auth MW: guard · Gateway authenticates protected requests
- API App → Rate Limit: throttle · Gateway applies request limiting
- API App → Auth Proxy: /api/auth · Public auth routes are proxied internally
- API App → Chat Proxy: /api/chat · Public chat routes are proxied internally
- Auth Proxy → Auth Route: forward · Forwards auth requests to the auth service
- Chat Proxy → Chat Routes: forward · Forwards chat requests to the chat service
- Auth Route → Auth Controller: handle · Routes dispatch to controllers
- Auth Controller → Auth Service: delegate · Controllers invoke auth logic
- Auth Service → Auth Model: read/write · Auth service persists user records
- Auth Service → Auth DB: connect · Uses MongoDB connection
- Auth Service → MongoDB: persist · Stores durable auth data
- Chat Routes → Chat Controllers: handle · Routes dispatch to chat controllers
- Chat Controllers → Chat Service: delegate · Controllers invoke chat logic
- Chat Service → Chat DB: connect · Uses MongoDB connection
- Chat Service → MongoDB: persist · Stores conversations and messages
- Chat Service → Message Event: publish · Emits message events after writes
- Message Event → Kafka: produce · Sends chat events to Kafka
- Kafka → Event Consumer: consume · Socket gateway consumes message events
- Event Consumer → Socket Events: emit · Transforms backend events into socket updates
- Socket Events → Socket Server: deliver · Pushes updates to connected clients
- Socket Server → Presence Service: track · Updates presence around connections
- Presence Service → Redis: store · Persists ephemeral presence state
- Redis → Kafka · Indirect support for realtime subsystem