Communication Between Systems

In the world of modern software architecture, one of the most critical decisions you must make is how your systems communicate with each other. It’s not just a technical matter; it’s a decision that affects performance, scalability, maintainability, and user experience.

I’ve worked with multiple forms of communication between systems: REST, GraphQL, WebSockets, gRPC, and Message Brokers. Each has its place, and choosing the wrong one can turn a promising project into a nightmare of latency and complexity.

The fundamental problem

When you build distributed systems, components need to communicate. But not all communication is the same. Some require immediate responses, others can be asynchronous. Some carry small data, others large volumes. Some need delivery guarantees, others can tolerate loss.

Understanding these differences is the key to choosing the right protocol.

REST: The universal standard

REST (Representational State Transfer) is probably the most common protocol for communication between systems. It’s simple, standard, and runs over HTTP, making it compatible with virtually any technology.

When to use REST

REST is ideal when:

• You need simplicity: It’s easy to understand, implement, and debug.
• You work with standard resources: CRUD (Create, Read, Update, Delete) over resources is the perfect use case.
• You need broad compatibility: Any HTTP client can consume your API.
• Data volume is moderate: REST works well for most use cases.

Advantages of REST

• Universal: Works with any language and framework.
• Cacheable: HTTP has built-in caching mechanisms.
• Stateless: Each request is independent, making scaling easier.
• Easy to debug: You can use tools like Postman or curl.

Disadvantages of REST

• Overfetching and Underfetching: You may get more data than needed or need multiple requests.
• Latency: Each request requires a full round-trip.
• No native streaming support: It’s not designed for real-time data.

Practical example

For standard public APIs, REST is ideal:

// Get a course
GET /api/courses/123

// Create a new course
POST /api/courses
{
  "title": "Software Architecture",
  "description": "..."
}

It’s simple, predictable, and works perfectly for CRUD operations.

GraphQL: Flexibility over the wire

GraphQL solves one of REST’s main problems: the need to make multiple requests or receive more data than needed.

When to use GraphQL

GraphQL is ideal when:

• You have clients with different needs: A mobile app needs less data than a desktop.
• You want to reduce the number of requests: A single query can fetch data from multiple resources.
• Your clients need control over data: They can specify exactly which fields they need.

Advantages of GraphQL

• Flexibility: The client defines what data it needs.
• Fewer round-trips: One query can fetch data from multiple resources.
• Strong typing: The schema defines exactly what’s possible.
• Excellent tools: GraphQL Playground, Apollo DevTools.

Disadvantages of GraphQL

• Complexity: Harder to implement and maintain than REST.
• Parsing overhead: The server must parse and validate complex queries.
• More complex caching: HTTP caching doesn’t work as well as with REST.
• Risk of complex queries: A client can make queries that overload the server.

Practical example

In an e-commerce system, instead of making multiple REST requests:

query {
  user(id: "123") {
    name
    email
    orders {
      id
      total
      items {
        product {
          name
          price
        }
      }
    }
  }
}

A single query gets everything needed.

WebSockets: Real-time communication

WebSockets provide persistent bidirectional communication between client and server. Unlike REST or GraphQL, which are request-response, WebSockets allow the server to send data to the client without the client requesting it.

When to use WebSockets

WebSockets are ideal when:

• You need real-time data: Chat, notifications, live updates.
• The server must initiate communication: The server needs to send data without waiting for a request.
• You have frequent communication: Multiple small messages are more efficient than multiple HTTP requests.

Advantages of WebSockets

• Low latency: Once the connection is established, communication is instant.
• Bidirectional: The server can send data when it’s available.
• Efficient: No HTTP header overhead on each message.

Disadvantages of WebSockets

• State complexity: Keeping connections open requires state management.
• Scalability: Scaling WebSockets is harder than stateless REST.
• Doesn’t work well with proxies: Some proxies and firewalls block WebSocket connections.

Practical example

For real-time notifications, WebSockets are ideal:

// Client connects
const ws = new WebSocket('wss://api.invitex.com/notifications');

// Server sends notification without client requesting it
ws.onmessage = (event) => {
  const notification = JSON.parse(event.data);
  // Show notification to user
};

gRPC: Binary speed

gRPC is an RPC (Remote Procedure Call) framework developed by Google. It uses Protocol Buffers for binary serialization, making it extremely efficient.

When to use gRPC

gRPC is ideal when:

• You need maximum performance: Binary serialization is faster than JSON.
• You work with microservices: Internal communication between services benefits from gRPC.
• You have well-defined contracts: Protocol Buffers provide strongly-typed contracts.
• You need streaming: gRPC natively supports bidirectional streaming.

Advantages of gRPC

• Performance: Binary serialization is faster than JSON.
• Strong typing: Contracts are defined in .proto files.
• Native streaming: Supports unidirectional and bidirectional streaming.
• Cross-platform: Works in any language that supports gRPC.

Disadvantages of gRPC

• Doesn’t work in browsers: Browsers don’t support gRPC directly (although gRPC-Web exists).
• Less readable: Binary messages aren’t as readable as JSON.
• Learning curve: Requires understanding Protocol Buffers and the gRPC ecosystem.

Practical example

In my Go storage system, I use gRPC for internal communication between microservices:

// Service definition in .proto
service StorageService {
  rpc UploadFile(stream Chunk) returns (UploadResponse);
  rpc DownloadFile(FileRequest) returns (stream Chunk);
}

// Usage in Go
client := storagepb.NewStorageServiceClient(conn)
stream, err := client.UploadFile(ctx)

gRPC efficiency is crucial when you’re moving large volumes of data between services.

Message Brokers: Asynchronous communication

Message Brokers like RabbitMQ or Kafka enable asynchronous communication between systems. Producers send messages to queues or topics, and consumers process them when ready.

When to use Message Brokers

Message Brokers are ideal when:

• You need decoupling: Systems don’t need to know each other directly.
• You can tolerate latency: Messages are processed when the consumer is available.
• You need delivery guarantees: Brokers can guarantee message delivery.
• You have variable workloads: Consumers can process messages at their own pace.

RabbitMQ vs. Kafka

RabbitMQ is ideal for:

• Task queues
• Point-to-point communication
• Immediate delivery guarantees
• Simpler systems

Kafka is ideal for:

• Event streaming
• High throughput
• Message retention
• Complex distributed systems

Advantages of Message Brokers

• Decoupling: Systems don’t need to know each other.
• Scalability: You can add more consumers to process more messages.
• Resilience: Messages are persisted and can be reprocessed.
• Delivery guarantees: Brokers guarantee message delivery.

Disadvantages of Message Brokers

• Operational complexity: They require additional infrastructure.
• Latency: Communication isn’t instant.
• Possible duplication: Messages may be processed multiple times (at-least-once delivery).

Practical example

In an e-commerce system, I use RabbitMQ to process orders asynchronously:

// Producer: when a user places an order
await channel.sendToQueue('order-processing', {
  orderId: '123',
  userId: '456',
  items: [...]
});

// Consumer: processes the order when available
channel.consume('order-processing', async (msg) => {
  const order = JSON.parse(msg.content.toString());
  await processOrder(order);
  channel.ack(msg);
});

The user doesn’t have to wait for inventory processing, confirmation email, and database updates. All of that happens asynchronously.

Quick comparison

Protocol	Latency	Complexity	Main use case
REST	Medium	Low	Standard APIs, CRUD
GraphQL	Medium	Medium	Flexible APIs, multiple clients
WebSockets	Low	Medium	Real-time, bidirectional
gRPC	Very low	High	Microservices, high performance
Message Brokers	Variable	High	Asynchronous processing

Practical use cases

REST for public APIs

For public APIs, REST is ideal. It’s simple, standard, and any client can consume it easily. For standard CRUD operations, REST is perfect.

gRPC for internal communication

For communication between microservices, gRPC is excellent. Binary serialization efficiency is crucial when you’re moving large volumes of data. Plus, strongly-typed contracts prevent runtime errors.

WebSockets for real-time

For real-time notifications, WebSockets are ideal. When a user receives a notification, they don’t have to refresh the page; the notification appears instantly.

RabbitMQ for async tasks

In e-commerce systems, RabbitMQ is perfect for processing orders, sending emails, and updating inventory asynchronously. This lets the response to the user be instant while heavy tasks run in the background.

Best practices

1. Choose based on use case

There’s no “best” protocol. Each has its place:

• REST: For most public APIs
• GraphQL: When clients need flexibility
• WebSockets: For real-time communication
• gRPC: For high-performance internal communication
• Message Brokers: For asynchronous processing

2. Consider latency

If latency is critical (e.g. trading systems or games), gRPC or WebSockets are better than REST. If you can tolerate latency (e.g. order processing), Message Brokers are an excellent choice.

3. Design for change

Protocols can change. Design your system so that switching from REST to gRPC, or adding a Message Broker, doesn’t require rewriting everything.

4. Implement observability

Whatever protocol you use, implement logging, metrics, and tracing. When something fails in a distributed system, you need to be able to trace the problem across multiple services.

5. Handle errors gracefully

Distributed systems fail. Design your system to handle timeouts, lost connections, and unavailable services. Implement retries, circuit breakers, and fallbacks.

My personal perspective

After working with all these protocols, I’ve reached a clear conclusion: the choice of communication protocol is as important as the system architecture.

I’ve seen projects that used REST for everything, even when they needed real-time communication, resulting in constant polling that overloaded servers. I’ve seen projects that used WebSockets when REST would have been enough, adding unnecessary complexity.

The key is to understand your system’s real needs:

• Do you need immediate responses? REST or gRPC.
• Does the server need to initiate communication? WebSockets.
• Can you process asynchronously? Message Brokers.
• Do clients need control over data? GraphQL.

In practice, use REST for most operations because it’s simple and sufficient. Use gRPC when performance is critical. Use WebSockets for notifications when real-time experience matters.

There’s no single answer. The best communication between systems is the one that fits your application’s real needs, not the one that’s trendy or technically most impressive.

At the end of the day, what matters is that your systems communicate efficiently, reliably, and maintainably. And that requires understanding the strengths and weaknesses of each option and choosing the right one for each specific use case.