Service Communication

Basic System Design
≈ 2 min read

Services Need a Way to Coordinate

When a system consists of several components, the internal logic of each service is no longer enough. Services need to request data from one another, send commands, publish events, and communicate the result of their work.

At a service boundary, the network, separate processes, and independent failures appear. That is why the communication style affects not only the request format, but also latency, coupling, failure behavior, and the ability to evolve parts of the system independently.

What We Will Cover

  • Service Communication Basics. We will see how a network call differs from a regular method call and why the contract between services becomes part of the architecture.
  • Synchronous Communication. We will examine the model where the calling service waits for a response and continues only after receiving it.
  • Asynchronous Communication. We will see how to hand work off without waiting for an immediate result and why this helps with unstable or heavy load.
  • REST. We will examine a common HTTP approach to APIs and the rules that make such an interface understandable for clients.
  • gRPC. We will get familiar with Protocol Buffers contracts and efficient RPC calls between services.
  • Messaging. We will see the role of a message broker between a sender and a receiver.
  • Request-Response. We will examine communication where one participant sends a request and expects a response associated with it.
  • Publish-Subscribe. We will see how one event can independently reach several subscribers.
  • Idempotency. We will learn to design operations so repeated delivery of a request or message does not corrupt system state.

We will first build a general model of an inter-service call, then compare delivery styles, after that examine concrete protocols and patterns, and finally address one of the main practical problems of distributed communication: duplicates.

Communication is part of system design. Two services can solve the right problems individually, yet the whole system can still be unreliable if the wrong communication style is chosen between them.