Request/Response

Overview of Request-Response Patterns

• The request-response pattern is a fundamental communication model in distributed systems, characterized by one component sending a request and waiting for a response.
• This typically results in synchronous communication, where progress is halted until a response is received.
• Three main types discussed: RPC (Remote Procedure Call), REST (Representational State Transfer), and GraphQL.

RPC (Remote Procedure Call)

• Enables communication by invoking procedures or methods on a remote service, following a client-server architecture.
• Common in monolithic architectures due to its simplicity and efficiency.
• Examples of RPC frameworks: XMLRPC, SOAP.
• Drawbacks include high coupling; any server-side changes can break the client integration.
• gRPC, a modern RPC framework, uses HTTP/2 and Protocol Buffers (Protobuf) for efficient, strongly-typed, language-neutral communication.
• gRPC offers backwards compatibility, schema sharing, and performance benefits but still involves endpoint and schema coupling.
• It is typically used for internal, inter-service communication within organizations rather than external/public APIs.
• gRPC can make network calls feel deceptively like local method calls, which can be dangerous due to the unreliability of networks.

REST (Representational State Transfer)

• The most common architectural style for distributed systems and microservices communication.
• Based on stateless client-server communication using URIs and standard HTTP methods (GET, POST, PUT, DELETE).
• RESTful APIs are simple, widely supported, and commonly used by SaaS providers (e.g., GitHub, Stripe).
• Data is usually transferred as JSON, with schema validation possible but not enforced by default.
• Most programming languages have robust frameworks for building and consuming REST APIs.
• Ideal for exposing APIs to broad audiences (web, mobile, third-party developers).
• Offers ease of use and widespread tools, but less efficient than gRPC for pure internal communication.

GraphQL

• A newer API technology developed by Facebook to address some REST limitations.
• Allows clients to request exactly the data they need, avoiding both over-fetching and under-fetching.
• Especially useful for scenarios requiring different data profiles (web vs. mobile), reducing data transfer and network roundtrips.
• Facilitates aggregation from multiple backend sources into a single response.
• Best suited for frontend APIs exposed to diverse clients with varying network conditions and data needs.
• Less suited for internal service-to-service communication, where REST or gRPC are typically preferable.

Choosing the Right Pattern

• Different use cases may require different patterns:
  • REST APIs are suitable for general frontend and third-party developer access.
  • Separate REST APIs or backend-for-frontend approaches may be used for web and mobile clients.
  • GraphQL can provide more flexibility for frontend clients with differing requirements.
  • gRPC is efficient for structured, internal microservice communication within trusted domains.
• Synchronous communication (as in request-response) introduces tight coupling; cascading failures can occur if internal dependencies are too rigid.
• Asynchronous communication is recommended for reducing coupling between internal services.
• Synchronous approaches remain appropriate for external-facing APIs (developers, web, and mobile frontends).

Suggested Action Items

• Assess current service communication patterns for appropriate use of synchronous (request-response) vs asynchronous styles.
• Consider using gRPC for internal microservice efficiency and strong schema contracts.
• Consider REST or GraphQL for external API surfaces, balancing ease-of-use and client data needs.
• Evaluate opportunities to reduce tight coupling and cascading failure risks in synchronous service-to-service calls.