Communication Between Services: Microservices and Messaging
InterviewPro Team
Senior Technical Interviewers
🎯 Build Like WhatsApp
This blog explains how services communicate using WhatsApp as our main example. You'll learn how real-time messaging systems work at scale.
Communication Between Services: Microservices and Messaging
Monolith vs Microservices 🏗️
What is a Monolith? 🏢
A monolith is a single application that does everything.
Example:
- 📁 One codebase
- 🗄️ One database
- 🚀 One deployment
- 📍 Everything in one place
What are Microservices? 🧩
Microservices are small, independent services that work together.
Example:
- 👤 User service (handles users)
- 💬 Message service (handles messages)
- 🔔 Notification service (handles notifications)
- 🗄️ Each service has its own database
- 🚀 Each service can be deployed independently
Why Do We Need Microservices? 🤔
💡Monolith vs Microservices Analogy
🏢 Monolith: Like one person doing everything - cooking, cleaning, accounting, marketing.
🧩 Microservices: Like a team of specialists - chef, cleaner, accountant, marketer, each doing their job.
Monolith Advantages ✅
- 🎯 Simple to develop initially
- ✅ Easy to test
- 🚀 Easy to deploy
- ⚡ No network calls between services
Monolith Disadvantages ❌
- 📉 Hard to scale individual parts
- 💥 One bug can crash everything
- 🔧 Difficult to maintain as it grows
- 🔒 Technology lock-in (must use same stack)
Microservices Advantages ✅
- 📈 Scale each service independently
- 🛡️ One service failure doesn't crash everything
- 👥 Different teams can work on different services
- 🛠️ Use different technologies for different services
Microservices Disadvantages ❌
- 🔧 More complex to develop
- 🧪 Harder to test (need to test communication)
- 🏗️ More infrastructure to manage
- 🌐 Network latency between services
Real-World Example: WhatsApp Evolution 💬
WhatsApp Started as Monolith:
- 📱 Single application
- 🎯 Simple to build
- ✅ Worked for initial users
WhatsApp Moved to Microservices:
- 👤 User service (authentication)
- 💬 Message service (sending/receiving)
- 📸 Media service (photos, videos)
- 🔔 Push notification service
- 📈 Each service scales independently
API Gateway 🚪
What is an API Gateway?
An API gateway is a single entry point for all client requests.
Examples:
- 📦 AWS API Gateway
- 🦍 Kong
- 🔵 Apigee
- 🎬 Netflix Zuul
Why Do We Need It?
💡API Gateway Analogy
❌ Without API Gateway: Like a building with many doors - users have to know which door to use for what.
✅ With API Gateway: Like a reception desk - users go to one place, and the receptionist directs them to the right service.
What Problem Does It Solve?
API gateways solve:
- 🚪 Single entry point for clients
- 🔐 Authentication and authorization
- ⏱️ Rate limiting
- 🧭 Request routing
- 📦 Response aggregation
How It Works
flowchart LR
A[👥 Users] --> B[🚪 API Gateway]
B --> C[👤 User Service]
B --> D[💬 Message Service]
B --> E[📸 Media Service]
B --> F[🔔 Notification Service]
style A fill:#e1f5ff
style B fill:#ffe1e1
style C fill:#e1ffe1
style D fill:#e1ffe1
style E fill:#e1ffe1
style F fill:#e1ffe1
Real-World Example: WhatsApp 💬
When you use WhatsApp:
- 📱 You open WhatsApp app
- 📤 All requests go to API Gateway
- 🔐 API Gateway checks if you're authenticated
- 🧭 API Gateway routes your request:
- 🔑 Login → User Service
- 💬 Send message → Message Service
- 📸 Upload photo → Media Service
- 📥 API Gateway sends response back to you
API Gateway Features ⚙️
Authentication:
- 🔑 Verify JWT tokens
- 👤 Check user permissions
- 🚫 Block unauthorized requests
Rate Limiting:
- 🛡️ Prevent spam
- ⚠️ Protect against abuse
- ⚖️ Ensure fair usage
Request Routing:
- 🧭 Send requests to correct service
- ⚖️ Load balance between service instances
- 🔧 Handle service failures
Response Aggregation:
- 📦 Combine responses from multiple services
- 🚀 Reduce client round trips
- 🎯 Simplify client code
Message Queue 📬
What is a Message Queue?
A message queue is a way for services to communicate asynchronously.
Examples:
- 🐰 RabbitMQ
- 📦 AWS SQS
- 🔵 Azure Service Bus
- ☁️ Google Cloud Pub/Sub
Why Do We Need It?
💡Message Queue Analogy
❌ Without Message Queue: Like calling someone and waiting on the line until they answer.
✅ With Message Queue: Like sending an email - you send it and continue with your day. The other person reads it when they can.
What Problem Does It Solve?
Message queues solve:
- 🔓 Service decoupling
- 📈 Handling bursts of traffic
- 📦 Reliable message delivery
- ⏱️ Asynchronous processing
How It Works
sequenceDiagram
participant ServiceA as ⚙️ Service A
participant Queue as 📬 Message Queue
participant ServiceB as ⚙️ Service B
ServiceA->>Queue: 📤 Send message
Queue->>Queue: 💾 Store message
ServiceB->>Queue: 📥 Get message
Queue->>ServiceB: 📤 Return message
ServiceB->>ServiceB: ⚙️ Process message
ServiceB->>Queue: ✅ Acknowledge
Queue->>Queue: 🗑️ Delete message
Real-World Example: WhatsApp 💬
When you send a message:
- 📤 Your message goes to Message Queue
- ⚙️ Message Service picks up message from queue
- 📱 Message Service delivers to recipient
- 🔕 If recipient is offline, message stays in queue
- 🟢 When recipient comes online, message is delivered
Kafka 📡
What is Kafka?
Kafka is a distributed streaming platform for handling real-time data streams.
Key Features:
- ⚡ High throughput (millions of messages per second)
- 🌐 Distributed (runs on multiple servers)
- 💾 Durable (messages stored on disk)
- ⏱️ Real-time processing
Why Do We Need It?
💡Kafka vs Message Queue
📬 Message Queue: Point-to-point communication (one sender, one receiver)
📡 Kafka: Pub-sub model (one sender, multiple receivers)
Kafka is like a radio broadcast - many people can listen to the same message.
What Problem Does It Solve?
Kafka solves:
- ⏱️ Real-time data streaming
- 📝 Event sourcing
- 📊 Log aggregation
- 🔄 Stream processing
Kafka Concepts 📚
Topic:
- 📁 A category or feed name to which messages are published
- 💬 Example: "user-messages", "click-events", "orders"
Producer:
- 📤 Sends messages to a topic
- 💬 Example: WhatsApp app sends messages to "user-messages" topic
Consumer:
- 👁️ Reads messages from a topic
- 🔔 Example: Notification service reads from "user-messages" topic
Partition:
- 🔀 Topics are divided into partitions for parallel processing
- 💬 Example: "user-messages" has 10 partitions for 10 consumers
Real-World Example: WhatsApp 💬
WhatsApp uses Kafka for:
Message Delivery:
- 📤 Producer: Your WhatsApp app
- 📁 Topic: "user-messages"
- 👁️ Consumers: Message delivery services
Analytics:
- 📤 Producer: All WhatsApp services
- 📁 Topic: "user-events"
- 📊 Consumers: Analytics services
flowchart TD
A[📱 WhatsApp App] --> B[📡 Kafka Topic: messages]
B --> C[📬 Delivery Service]
B --> D[📊 Analytics Service]
B --> E[💾 Backup Service]
F[📱 WhatsApp App] --> G[📡 Kafka Topic: events]
G --> H[📊 Analytics Service]
G --> I[🤖 ML Service]
style A fill:#e1f5ff
style F fill:#e1f5ff
style B fill:#ffe1e1
style G fill:#ffe1e1
RabbitMQ 🐰
What is RabbitMQ?
RabbitMQ is a message broker that implements the AMQP protocol.
Key Features:
- 🧭 Flexible routing
- 🔌 Multiple messaging protocols
- 📦 Reliable message delivery
- 🎯 Easy to set up
Why Do We Need It?
💡Kafka vs RabbitMQ
📡 Kafka: High throughput, real-time streaming, big data
🐰 RabbitMQ: Flexible routing, reliable delivery, traditional messaging
Use Kafka for streaming, RabbitMQ for reliable messaging.
What Problem Does It Solve?
RabbitMQ solves:
- 🔀 Complex routing patterns
- 📦 Reliable message delivery
- 💳 Transactional messaging
- 🔌 Multiple protocol support
RabbitMQ Concepts 📚
Exchange:
- 📥 Receives messages from producers
- 🧭 Routes messages to queues
- 📋 Types: Direct, Topic, Fanout, Headers
Queue:
- 💾 Stores messages until consumed
- 👥 Can have multiple consumers
- ✅ Messages are acknowledged when processed
Binding:
- 🔗 Links exchange to queue
- 🔑 Uses routing keys
- 🧭 Determines message routing
Real-World Example: E-commerce 🛒
When you place an order:
- 🛒 Order service sends message to RabbitMQ
- 🧭 Exchange routes message to multiple queues:
- 📦 Inventory queue (update stock)
- 💳 Payment queue (process payment)
- 🚚 Shipping queue (prepare shipping)
- 📧 Email queue (send confirmation)
- ⚙️ Each service processes its message independently
Background Jobs ⏰
What are Background Jobs?
Background jobs are tasks that run asynchronously, not in the main request-response cycle.
Examples:
- 📧 Sending emails
- 🖼️ Processing images
- 📊 Generating reports
- 🧹 Cleaning up old data
Why Do We Need It?
💡Background Jobs Analogy
❌ Without Background Jobs: Like a restaurant where the chef stops cooking to answer the phone every time it rings.
✅ With Background Jobs: Like a restaurant where a receptionist answers calls while chefs keep cooking.
What Problem Does It Solve?
Background jobs solve:
- 🐌 Slow user requests
- ⏱️ Timeout issues
- 💪 Resource intensive tasks
- 📅 Scheduled tasks
Real-World Example: Instagram 📸
When you upload a photo:
- 📤 Photo uploads to file storage (fast)
- ⏰ Background job processes photo:
- 🖼️ Resize to multiple sizes
- 🖼️ Generate thumbnail
- 🎨 Apply filters
- 🗄️ Update database
- ✅ You see "Upload complete" immediately
- ⚙️ Processing happens in background
sequenceDiagram
participant User as 👤 You
participant API as 🚪 API
participant Queue as 📬 Job Queue
participant Worker as ⚙️ Background Worker
User->>API: 📤 Upload photo
API->>User: ✅ Upload complete
API->>Queue: 📝 Add processing job
Queue->>Worker: 📤 Send job
Worker->>Worker: ⚙️ Process photo
Worker->>API: ✅ Job complete
Event Driven Architecture ⚡
What is Event Driven Architecture?
Event driven architecture is a pattern where services communicate through events.
Key Concept:
- ⚙️ Service A does something
- 📢 Service A emits an event
- 👂 Other services listen for events
- 🔄 Services react to events
Why Do We Need It?
💡Event Driven vs Request-Response
📞 Request-Response: Service A asks Service B to do something and waits for answer.
⚡ Event Driven: Service A does something and announces it. Other services react if they care.
What Problem Does It Solve?
Event driven architecture solves:
- 🔓 Service coupling
- ⏱️ Real-time updates
- 🔀 Complex workflows
- 📈 Scalability
Real-World Example: WhatsApp 💬
User sends message event:
- 💬 Message Service emits "message-sent" event
- 🔔 Notification Service listens and sends push notification
- 📊 Analytics Service listens and logs event
- 💾 Backup Service listens and saves message
- 🤖 ML Service listens and updates recommendations
All services react independently to the same event.
flowchart TD
A[💬 Message Service] --> B[📡 Event Bus]
B --> C[🔔 Notification Service]
B --> D[📊 Analytics Service]
B --> E[💾 Backup Service]
B --> F[🤖 ML Service]
style A fill:#e1f5ff
style B fill:#ffe1e1
style C fill:#e1ffe1
style D fill:#e1ffe1
style E fill:#e1ffe1
style F fill:#e1ffe1
WebSocket 🔌
What is WebSocket?
WebSocket is a communication protocol that provides full-duplex communication channels.
Key Feature:
- 🔗 Persistent connection between client and server
- 💬 Both can send messages anytime
- ⏱️ Real-time communication
Why Do We Need It?
💡WebSocket vs HTTP
📞 HTTP: Client asks, server answers, connection closes. Like sending letters.
🔌 WebSocket: Connection stays open. Both can talk anytime. Like a phone call.
What Problem Does It Solve?
WebSocket solves:
- ⏱️ Real-time communication
- 🚀 Low latency updates
- 💬 Bidirectional messaging
- 📉 Reduced overhead
Real-World Example: WhatsApp 💬
When you chat on WhatsApp:
- 📱 Your app opens WebSocket connection to server
- 🔗 Connection stays open while you're chatting
- 💬 You send messages through WebSocket
- 📤 Server sends new messages through WebSocket
- 🚫 No need to keep asking "are there new messages?"
sequenceDiagram
participant Client as 📱 Your App
participant Server as 🖥️ WhatsApp Server
Client->>Server: 🔌 Open WebSocket
Server->>Client: ✅ Connection established
Client->>Server: 💬 Send message
Server->>Client: ✅ Message delivered
Server->>Client: 📨 New message received
Client->>Server: ✅ Read receipt
Polling 🔄
What is Polling?
Polling is when a client repeatedly asks the server if there's new data.
Example:
- 📱 Client: "Any new messages?" (every 5 seconds)
- 🖥️ Server: "No" / "Yes, here they are"
Why Do We Need It?
💡Polling vs WebSocket
🔄 Polling: Client keeps asking "anything new?" Wasteful but simple.
🔌 WebSocket: Server tells client when something new happens. Efficient but complex.
What Problem Does It Solve?
Polling solves:
- 🎯 Simple real-time updates
- 🌐 Works with HTTP
- 🎯 Easy to implement
- 🚫 No persistent connection needed
Disadvantages ❌
- 💸 Wasteful (many empty responses)
- ⏱️ Not truly real-time (delay between polls)
- 🖥️ Server load from constant requests
- 🔋 Battery drain on mobile devices
Real-World Example: Email 📧
Your email app polls for new messages:
- ⏰ Every 5 minutes: "Any new emails?"
- 🖥️ Server: "No" or "Yes, here are new emails"
- 👁️ You see new emails appear
Real-World Example: WhatsApp Architecture 💬
Let's put everything together with WhatsApp:
User Registration 👤
flowchart LR
A[👤 User registers] --> B[🚪 API Gateway]
B --> C[👤 User Service]
C --> D[🗄️ Database]
C --> E[📡 Event Bus]
E --> F[📧 Email Service]
E --> G[📊 Analytics Service]
Sending a Message 💬
flowchart LR
A[👤 User sends message] --> B[🔌 WebSocket]
B --> C[💬 Message Service]
C --> D[📡 Kafka]
D --> E[📬 Delivery Service]
D --> F[📊 Analytics Service]
D --> G[💾 Backup Service]
E --> H[👤 Recipient]
Uploading a Photo 📸
flowchart LR
A[👤 User uploads photo] --> B[🚪 API Gateway]
B --> C[📸 Media Service]
C --> D[📁 File Storage]
C --> E[📬 Job Queue]
E --> F[⚙️ Background Worker]
F --> G[🖼️ Process Image]
G --> H[🗄️ Update Database]
Real-time Notifications 🔔
flowchart LR
A[💬 New message] --> B[📡 Event Bus]
B --> C[🔔 Notification Service]
C --> D[📱 Push Service]
D --> E[📱 User Device]
Summary 📚
💡Communication Key Points
- 🏢 Monolith = Single application doing everything
- 🧩 Microservices = Small independent services working together
- 🚪 API Gateway = Single entry point for all requests
- 📬 Message Queue = Asynchronous communication between services
- 📡 Kafka = Real-time data streaming platform
- 🐰 RabbitMQ = Reliable message broker with flexible routing
- ⏰ Background Jobs = Tasks that run asynchronously
- ⚡ Event Driven = Services communicate through events
- 🔌 WebSocket = Real-time bidirectional communication
- 🔄 Polling = Client repeatedly asks for updates
Comparison Table 📊
| Technology | Best For | Complexity | Use Case | |------------|----------|------------|----------| | 🏢 Monolith | Small apps | 🟢 Low | 🚀 Starting out | | 🧩 Microservices | Large apps | 🔴 High | 📈 Scalable systems | | 🚪 API Gateway | Multiple services | 🟡 Medium | 🎯 Single entry point | | 📬 Message Queue | Async tasks | 🟡 Medium | ⏰ Background jobs | | 📡 Kafka | Real-time streaming | 🔴 High | ⚡ Event streaming | | 🐰 RabbitMQ | Reliable messaging | 🟡 Medium | 🔀 Complex routing | | 🔌 WebSocket | Real-time updates | 🟡 Medium | 💬 Chat, live updates | | 🔄 Polling | Simple updates | 🟢 Low | 📧 Email, notifications |
Common Interview Questions 📝
📝 Practice Questions
- What is the difference between monolith and microservices?
- What does an API gateway do?
- Explain when to use a message queue.
- What is the difference between Kafka and RabbitMQ?
- What are background jobs and when would you use them?
- Explain event driven architecture.
- What is WebSocket and when would you use it?
- What is the difference between polling and WebSocket?
What's Next? 🚀
Now that you understand service communication, the final blog will cover:
- 🏗️ Putting everything together
- 🌐 End-to-end architecture
- 🚀 Deployment basics
- 🐳 Docker and Kubernetes
- ☁️ Cloud fundamentals
- 💡 Interview tips
✅ Almost There!
You now understand how services communicate. Continue to the final blog to learn how to put everything together into a complete system.