Why Microservice communication basics in Express? - Purpose & Use Cases

The Big Idea

What if your app parts could chat perfectly without missing a beat?

The Scenario

Imagine you have a big team project where everyone works separately, but you need to share notes by shouting across the room.

Each person tries to listen and respond, but messages get lost or misunderstood.

The Problem

Shouting notes manually is slow and confusing.

People miss messages or reply late, causing delays and mistakes.

It's hard to keep track of who said what and when.

The Solution

Microservice communication basics teach us how to set up clear, reliable ways for small teams (services) to talk.

They use organized channels like phone calls or emails instead of shouting.

This makes messages clear, timely, and easy to follow.

Before vs After

✗ Before

serviceA.send('data') // no confirmation, no retry

✓ After

serviceA.request('data').then(response => handle(response))

What It Enables

It enables building complex apps where small parts work smoothly together without confusion.

Real Life Example

Think of an online store where the payment service talks to the inventory service to update stock instantly and correctly.

Key Takeaways

Manual message passing is unreliable and slow.

Microservice communication uses clear, reliable methods.

This helps build fast, scalable, and maintainable systems.

Practice

1. Which of the following is a common way for microservices to communicate synchronously in an Express-based system?

easy

A. Sharing global variables in memory

B. Direct database access by all services

C. Using HTTP REST API calls between services

D. Using local file system for message passing

Solution

1. Step 1: Understand synchronous communication in microservices

   Synchronous communication means one service waits for a response from another before continuing.

2. Step 2: Identify common synchronous methods in Express

   HTTP REST API calls are widely used for synchronous communication between microservices in Express.

3. Final Answer:

   Using HTTP REST API calls between services -> Option C

4. Quick Check:

   Synchronous communication = HTTP REST API calls [OK]

Hint: Sync communication usually uses HTTP requests [OK]

Common Mistakes:

• Thinking direct DB access is common for microservices
• Assuming shared memory works across services
• Using file system for communication

2. Which Express code snippet correctly sends a JSON response from one microservice to another?

easy

A. res.json({ data: 'value' })

B. res.write({ data: 'value' })

C. res.send("{ data: 'value' }")

D. res.render({ data: 'value' })

Solution

1. Step 1: Identify Express method for JSON response

   Express provides res.json() to send JSON formatted responses easily.

2. Step 2: Compare other methods

   res.send() can send JSON but res.json() is preferred for clarity; res.write() is low-level and res.render() is for templates.

3. Final Answer:

   res.json({ data: 'value' }) -> Option A

4. Quick Check:

   Express JSON response = res.json() [OK]

Hint: Use res.json() to send JSON responses in Express [OK]

Common Mistakes:

• Using res.send() without JSON stringification
• Confusing res.render() with JSON response
• Using res.write() incorrectly

3. Consider two microservices where Service A calls Service B using HTTP GET. What will Service A receive if Service B responds with res.status(200).json({ message: 'Success' })?

medium

A. A JSON object { message: 'Success' }

B. A plain text 'Success' string

C. An HTTP 404 error

D. An empty response

Solution

1. Step 1: Understand Service B's response

   Service B sends HTTP status 200 with JSON body { message: 'Success' }.

2. Step 2: Determine what Service A receives

   Service A receives the JSON object exactly as sent, since status 200 means OK and body is JSON.

3. Final Answer:

   A JSON object { message: 'Success' } -> Option A

4. Quick Check:

   HTTP 200 + res.json() = JSON object response [OK]

Hint: HTTP 200 with res.json() returns JSON object [OK]

Common Mistakes:

• Assuming plain text instead of JSON
• Confusing status codes with response body
• Expecting empty or error response

4. In an Express microservice, the following code is used to call another service asynchronously. What is the main issue?

fetch('http://service-b/api/data')
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.log(error))

medium

A. Missing await keyword for fetch call

B. fetch is not defined in Node.js by default

C. No error handling for non-JSON responses

D. Using console.log instead of res.send

Solution

1. Step 1: Check environment support for fetch

   Node.js versions before 18 do not have fetch globally defined by default.

2. Step 2: Identify the main issue in Express microservice

   Without importing or enabling fetch, this code will cause a ReferenceError in Node.js.

3. Final Answer:

   fetch is not defined in Node.js by default -> Option B

4. Quick Check:

   Node.js needs fetch polyfill or version 18+ [OK]

Hint: Node.js needs fetch polyfill or v18+ for fetch [OK]

Common Mistakes:

• Thinking await is mandatory with then() chains
• Ignoring fetch availability in Node.js
• Confusing console.log with response sending

5. You want to design communication between two Express microservices where Service A sends a task to Service B and does not wait for a response. Which approach is best to ensure reliable, scalable communication?

hard

A. Use WebSocket connection for real-time two-way communication

B. Use HTTP POST with immediate response from Service B

C. Use direct database writes by Service A for Service B to poll

D. Use a message queue like RabbitMQ for asynchronous messaging

Solution

1. Step 1: Understand asynchronous communication needs

   Service A sends a task and does not wait, so async messaging is needed.

2. Step 2: Evaluate options for reliability and scalability

   Message queues like RabbitMQ provide reliable, scalable async communication with delivery guarantees.

3. Final Answer:

   Use a message queue like RabbitMQ for asynchronous messaging -> Option D

4. Quick Check:

   Async + reliable + scalable = message queue [OK]

Hint: Async tasks use message queues for reliability [OK]

Common Mistakes:

• Using HTTP POST expecting async without waiting
• Relying on database polling which is inefficient
• Using WebSocket for one-way async tasks