Microservice communication basics in Express - Deep Dive

Overview - Microservice communication basics

What is it?

Microservice communication basics explain how small, independent services talk to each other in a system. Each microservice does one job and needs to share data or requests with others. This communication can happen in different ways, like sending messages or calling APIs. Understanding this helps build systems that work well together and can grow easily.

Why it matters

Without clear communication methods, microservices would be isolated and unable to cooperate, making the system fail or become very hard to fix. Good communication lets services share work smoothly, handle failures better, and scale independently. This means apps can be faster, more reliable, and easier to update without breaking everything.

Where it fits

Before learning this, you should know basic web servers and APIs, especially how Express handles requests and responses. After this, you can explore advanced topics like service discovery, API gateways, and event-driven architectures to build more complex microservice systems.

Mental Model

Core Idea

Microservices communicate by sending messages or requests to each other to share data and coordinate tasks, like people passing notes or making phone calls.

Think of it like...

Imagine a team where each member has a specific job and they talk by passing notes or calling each other to get things done together without being in the same room.

┌─────────────┐      ┌─────────────┐      ┌─────────────┐
│ Microservice│─────▶│ Microservice│─────▶│ Microservice│
│     A       │      │     B       │      │     C       │
└─────────────┘      └─────────────┘      └─────────────┘
       ▲                    │                    │
       │                    ▼                    ▼
  Client/API           Request/Response     Event/Message

Build-Up - 7 Steps

1

Foundation

What are Microservices

Concept: Introduce the idea of microservices as small, focused services that work together.

Microservices are like tiny apps that each do one job well. Instead of one big app, you have many small ones. Each microservice runs independently and can be built or fixed without touching others.

Result

You understand that microservices break big problems into smaller parts that communicate.

Knowing microservices are independent helps you see why communication between them is needed.

2

Foundation

Express Basics for Microservices

Concept: Learn how Express creates simple web servers that microservices use to talk.

Express lets you build a server that listens for requests and sends responses. Each microservice can use Express to expose endpoints other services call to get data or trigger actions.

Result

You can create a basic Express server that handles requests, the foundation for microservice communication.

Understanding Express servers is key because microservices often communicate via HTTP requests.

3

Intermediate

Synchronous Communication with HTTP

🤔Before reading on: do you think synchronous communication means services wait for each other or work independently? Commit to your answer.

Concept: Explore how microservices call each other directly using HTTP requests and wait for responses.

In synchronous communication, one microservice sends an HTTP request to another and waits for the reply before continuing. For example, Service A asks Service B for user data and waits until it gets the data back.

Result

You see how services depend on each other’s responses and how delays or failures can affect the whole system.

Knowing synchronous calls can cause waiting helps you understand potential bottlenecks and failure points.

4

Intermediate

Asynchronous Communication with Messaging

🤔Before reading on: do you think asynchronous communication means services respond immediately or later? Commit to your answer.

Concept: Learn how microservices send messages without waiting for immediate replies, using queues or event buses.

Asynchronous communication means a service sends a message to a queue or topic and continues working without waiting. Another service picks up the message later and processes it. This reduces waiting and improves resilience.

Result

You understand how services can work independently and handle tasks at their own pace.

Understanding asynchronous messaging reveals how systems stay responsive and handle failures better.

5

Intermediate

Common Protocols and Formats

Concept: Introduce HTTP, REST, gRPC, and message formats like JSON and Protobuf used in communication.

Microservices use protocols like HTTP for REST APIs or gRPC for faster calls. They exchange data in formats like JSON (easy to read) or Protobuf (compact and fast). Choosing the right protocol and format affects speed and compatibility.

Result

You can identify when to use different communication methods and data formats.

Knowing protocols and formats helps you design efficient and compatible microservice interactions.

6

Advanced

Handling Failures and Timeouts

🤔Before reading on: do you think a failed microservice call crashes the whole system or can be managed gracefully? Commit to your answer.

Concept: Learn strategies to handle communication failures like retries, timeouts, and circuit breakers.

Microservices can fail or be slow. To avoid crashes, services use timeouts to stop waiting, retries to try again, and circuit breakers to stop calling failing services temporarily. These patterns keep the system stable.

Result

You see how to make microservice communication reliable even when parts fail.

Understanding failure handling is crucial to building resilient microservice systems.

7

Expert

Service Discovery and Load Balancing

🤔Before reading on: do you think microservices always know each other's addresses or need help finding them? Commit to your answer.

Concept: Explore how microservices find each other dynamically and distribute requests evenly.

In large systems, services move or scale, so their addresses change. Service discovery tools keep track of where services are. Load balancers spread requests across multiple instances to avoid overload. This keeps communication smooth and scalable.

Result

You understand how microservices stay connected and balanced in complex environments.

Knowing dynamic discovery and load balancing prevents hardcoded addresses and bottlenecks.

Under the Hood

Microservice communication happens over networks using protocols like HTTP or messaging systems. When a service sends a request, it opens a network connection, sends data formatted in JSON or Protobuf, and waits or continues based on sync or async mode. Messaging systems use brokers to store and forward messages reliably. Internally, services serialize data, manage connections, and handle retries or failures automatically.

Why designed this way?

This design separates concerns: each microservice focuses on its job and communicates via standard protocols to stay independent. Using HTTP and messaging allows flexibility and language-agnostic communication. The tradeoff is added complexity in managing network calls and failures, but it enables scalability and easier maintenance compared to monolithic apps.

┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Microservice A│─────▶│ Network Layer │─────▶│ Microservice B│
│ (Express API) │      │ (HTTP/MQ)     │      │ (Express API) │
└───────────────┘      └───────────────┘      └───────────────┘
       │                      ▲                      │
       │                      │                      │
       ▼                      │                      ▼
  Serialize                Broker                 Deserialize
  (JSON/Protobuf)          (Message Queue)        (JSON/Protobuf)

Myth Busters - 4 Common Misconceptions

Quick: Do microservices always communicate synchronously? Commit to yes or no.

Common Belief: Microservices mostly communicate synchronously by calling each other's APIs directly.

Reality: Many microservices use asynchronous messaging to avoid waiting and improve resilience.

Why it matters: Assuming only synchronous calls leads to designs that are fragile and slow under load.

Quick: Do you think microservices must know each other's exact network address? Commit to yes or no.

Common Belief: Each microservice hardcodes the address of the others it needs to call.

Reality: Microservices use service discovery to find each other dynamically, avoiding hardcoded addresses.

Why it matters: Hardcoding addresses breaks scaling and deployment flexibility, causing failures.

Quick: Do you think message queues guarantee message delivery without loss? Commit to yes or no.

Common Belief: Using a message queue means messages are always delivered safely and in order.

Reality: Message queues improve reliability but can lose or reorder messages without proper configuration and handling.

Why it matters: Ignoring this can cause data loss or inconsistent system states.

Quick: Do you think microservices communication is always simple and fast? Commit to yes or no.

Common Belief: Communication between microservices is straightforward and adds little overhead.

Reality: Network calls add latency and complexity, requiring careful design to avoid slowdowns.

Why it matters: Underestimating communication costs leads to poor performance and user experience.

Expert Zone

1

Microservice communication patterns often combine synchronous and asynchronous calls depending on use case and latency tolerance.

2

Choosing between REST and gRPC depends on factors like language support, performance needs, and backward compatibility.

3

Circuit breakers not only prevent cascading failures but also provide valuable metrics for system health monitoring.

When NOT to use

Microservice communication basics are less suitable for very simple or monolithic applications where internal function calls suffice. In such cases, direct method calls or shared memory are better. Also, for extremely low-latency needs, tightly coupled systems or in-process communication might be preferred.

Production Patterns

In production, microservices often use API gateways to centralize communication, implement retries with exponential backoff, and use message brokers like RabbitMQ or Kafka for event-driven flows. Service meshes add observability and security layers to communication. These patterns improve reliability, scalability, and maintainability.

Connections

Event-Driven Architecture

Builds-on asynchronous microservice communication using events and messaging.

Understanding microservice communication basics helps grasp how events trigger workflows across services without tight coupling.

Networking Protocols

Shares underlying principles of data transmission and connection management.

Knowing how TCP/IP and HTTP work deepens understanding of microservice communication reliability and latency.

Human Team Collaboration

Analogous to how team members coordinate tasks via messages and meetings.

Seeing microservices as team members clarifies why clear communication methods and failure handling are essential.

Common Pitfalls

#1 Calling microservices synchronously without timeouts causes the whole system to hang if one service is slow.

Wrong approach:

await fetch('http://service-b/api/data'); // no timeout or error handling

Correct approach:

const controller = new AbortController();
setTimeout(() => controller.abort(), 3000);
await fetch('http://service-b/api/data', { signal: controller.signal });

Root cause:

Not handling network delays or failures leads to blocking calls that freeze the system.

#2 Hardcoding service URLs in code makes scaling and deployment brittle.

Wrong approach:

const serviceBUrl = 'http://localhost:3001/api';

Correct approach:

const serviceBUrl = serviceDiscovery.getUrl('service-b');

Root cause:

Ignoring dynamic environments causes failures when services move or scale.

#3 Assuming message queues guarantee order and delivery without configuring acknowledgments.

Wrong approach:

producer.send(message); // no confirmation or retry

Correct approach:

producer.send(message, { ack: true }); // confirm delivery and retry if needed

Root cause:

Misunderstanding message queue guarantees leads to lost or duplicated messages.

Key Takeaways

Microservices communicate by sending requests or messages to share data and coordinate work.

Synchronous communication waits for responses and can cause delays, while asynchronous messaging improves resilience.

Protocols like HTTP and formats like JSON are common, but choices affect performance and compatibility.

Handling failures with timeouts, retries, and circuit breakers is essential for reliable systems.

Dynamic service discovery and load balancing keep microservices connected and scalable in real environments.