Intercommunication in the world of micro services

I always wondered what can be the different ways in which the microservices can commmunicate with each other. Like majority of us I almost instintively thought of REST or SOAP as two prominant ways of passing data over internet, but are there other better ways of making the different components of an enterprise systen talk to each other? If yes what is the purpose of their existance, lets address these and other related queries in this article.

The manner in which micro services talk to each other can be classified in four major categories:

1. Synchronous Communication
2. Asynchronous Communication
3. Database Level Communication
4. Hybrid

Lets explore them one by one - 

Synchronous Communication

In this style of inter service communication a sender service requests some resource from its counterpart and then waits for the response before proceeding ahead. This is also called blocking mode because the caller is blocked till it gets wahat it had requested. Lets explore some protocols which use this style of inter system communication.

HTTP/REST APIs

   Description:

In REST based services communicate over HTTP using REST APIs (typically JSON). Each service exposes endpoints that others can call directly.

REST is most common and well-understood method of service communication. Based on standard HTTP verbs.

    Pros:

• Easy to implement and debug

• Language-agnostic (can be used by any tech stack)

• Wide tool support

• Human-readable payloads (JSON)

    Cons:

• Tight coupling. Communicating services need to know the API exposed by other services.

• Blocking calls—waiting for response

• Error handling and retries can be complex

• Not ideal for high-throughput or low-latency systems

GraphQL

   Description:

In GraphQL service communication, multiple services expose a GraphQL schema and federate it into a single API gateway. GraphQL combines data from multiple services into a single unified API for clients.

    Pros:

• Fine-grained data fetching

• Reduces over-fetching/under-fetching

• Good for BFF (Backend-for-Frontend) patterns

    Cons:

• Complex schema management

• Federation setup requires tooling and orchestration

• Performance overhead due to stitching. 

  GraphQL stitching is the technique of combining multiple GraphQL schemas into a single unified schema, so that clients can query data from multiple services through a single GraphQL endpoint.

gRPC

    Description:

A high-performance, open-source RPC framework developed by Google using Protocol Buffers (protobufs) for serialization.

Great for performance-critical, low-latency communication between services, especially in polyglot             systems.

    Pros:

• Extremely fast due to binary protocol

• Contract-first (proto file)

• Supports bidirectional streaming

• Code generation in multiple languages

    Cons:

• Steeper learning curve than REST

• Harder to debug manually (non-human-readable payload)

• Limited browser support (needs gRPC-Web HTTP/2 for frontend)

Asynchronous Communication

This style of comunication i also called nonblocking, where once the caller requests a resource it doesn't need to stop processing ahead. The calling service continues to execute the next steps and blocks only when it actually need to use the requested result.

Message Queues (RabbitMQ, Apache Kafka, Amazon SQS)

   Description:

        Services communicate by publishing and consuming messages via an intermediary queue or topic.

        MQs decouples services and allows for async processing and eventual consistency.

    Pros:

• Loose coupling

• Scalable and resilient

• Supports async and event-driven patterns

• Good for bursty workloads

    Cons:

• Increased system complexity

• Requires monitoring and tuning of brokers

• Harder to debug than synchronous calls

• Potential message loss or duplication if not handled properly

Event Streaming (Apache Kafka, Amazon Kinesis)

    Description:

Microservices produce and react to events instead of calling each other directly. Events are emitted and subscribed to using an event bus.

Event driven architecture is highly decoupled and scalable architecture for real-time data pipelines and reactive systems.

    Pros:

• High scalability and flexibility

• Promotes eventual consistency

• Natural fit for audit logs and analytics

• Enables microservices to evolve independently

• supports multiple consumers, 

    Cons:

• Hard to track execution flow (distributed tracing needed)

• Event schema evolution needs careful handling

• Increased operational overhead

• Message ordering challenges, 
• potential message loss, 
• complex error handling

Database-Level Communication

Shared Database

    Description:

        Two or more services access the same database schema or tables.

        Sometimes used for legacy systems or tightly integrated services.

    Pros:

• Simple to implement initially

• No need for service communication layer

    Cons:

• Breaks service encapsulation

• Tight coupling via data layer

• High risk of data integrity issues

• Not scalable

Shared database design is Generally discouraged in microservice design

Database per Service with Event Sourcing

Services store state changes as events and communicate by sharing these event streams.

Each service owns its data, communicates state changes through events

    Pros: 

• Data ownership, 
• audit trail, 
• temporal queries, 
• eventual consistency handling

    Cons: 

• Complex implementation, 
• storage overhead, 
• event schema evolution, 
• debugging complexity

WebSockets / Streaming APIs (Async or Real-Time)

Description 

Maintains a persistent, two-way communication channel between services. 

Ideal for real-time use cases like notifications, live feeds, collaborative tools.

    Pros:

• Real-time bidirectional communication
• Low latency
• Efficient for push-based updates

    Cons:

• Stateful connections are harder to scale
• Requires careful resource and connection management
• Less standard than REST or gRPC

Hybrid Approaches

API Gateway Pattern

Centralized proxy that routes external requests to appropriate microservices and handles cross-cutting concerns.

    Pros: 

• Centralized cross-cutting concerns,
• request routing, 
• rate limiting, 
• authentication

    Cons: 

• Potential bottleneck, 
• single point of failure, 
• increased latency

Service Mesh (Istio, Linkerd)

Infrastructure layer that manages all service-to-service communication with built-in security,                         monitoring, and traffic control.

    Pros: 

• Traffic management, 
• Security, 
• Observability, 
• Policy enforcement without code changes

    Cons: 

• Operational complexity, 
• Resource overhead, 
• Learning curve, 
• Debugging challenges

Choreography vs Orchestration

    Orchestration: Central service coordinates and manages workflows across multiple microservices.

    Choreography: Services coordinate through events without a central controller, each service knows             how to react to events.

Choreography uses events for decentralized coordination while orchestration uses a central coordinator

    Pros(Choreography): 

• Loose coupling, 
• resilient to failures, 
• scalable

    Cons(Choreography): 

• Hard to track business processes, 
• potential cycles

    Pros (Orchestration): 

• Clear business logic, 
• easier monitoring, 
• centralized control

    Cons (Orchestration): 

• Central point of failure, 
• tighter coupling

The choice depends on your specific requirements for consistency, performance, scalability, and operational complexity. Many systems use a combination of these approaches, with synchronous communication for immediate responses and asynchronous for background processing and event notifications.