Service-to-Service Communication.

What it is

Service-to-service communication means one backend service asks another backend service for help. In Spring Boot, that usually means an HTTP client inside one application calling an HTTP endpoint in another application, although the same idea also applies to events, queues, and gRPC. The important part is not the transport; it is the dependency: one service cannot finish until another service responds.

How it works under the hood

The caller receives a request and decides it needs data from another service.
It resolves the target address from a property, DNS name, or service registry such as Eureka or Consul. In Spring Boot, this is often hidden behind a base URL or a client bean.
The HTTP client opens or reuses a TCP connection. If TLS is enabled, the client also negotiates encrypted transport before sending business data.
The caller sends the request plus headers such as authorization and a correlation ID, which is a shared tracking value for one user flow.
The downstream service processes the request, hits its own database or cache, and returns success or an error code like 404, 409, or 503.
The caller translates that response into its own domain language: maybe it creates an order, shows an out-of-stock message, or returns a service-unavailable error.
If the call is unreliable, the caller may retry, fallback, or open a circuit breaker, which is a fast-fail switch that stops repeated calls to a failing dependency.

When to use it

Use synchronous HTTP when the user is waiting for an immediate answer, such as inventory lookup, pricing, or customer verification.
Use asynchronous messaging when the work is long-running, can be done later, or does not need an instant response, such as sending emails or rebuilding a search index.
Use a gateway when outside clients should not talk to every service directly. Inside the cluster, service-to-service calls are still common for private workflows.

Which style to choose

Style	Best for	Main trade-off
Sync HTTP	Immediate replies	Blocks caller thread
WebClient	High concurrency	More reactive code
Messaging	Long tasks	Eventual consistency

Spring Boot gives you a few practical choices. `RestTemplate` is the classic blocking client and still helps you understand the flow. `RestClient` is the newer blocking API in modern Spring, and `WebClient` is the non-blocking choice when you need more throughput. `OpenFeign` is a declarative wrapper that removes boilerplate, but it still makes the same underlying network call, so timeouts and retries still matter.

Performance and edge cases

A remote call is O(1) in local code, but the real cost is network latency and waiting. Inside one cluster, a call often adds about 5 to 50 ms; across zones or regions it can be much more. A blocking client also holds one server thread while waiting, so five nested calls can pin five threads for one user request. If a service handles 200 threads and each downstream call waits 2 seconds, the path can top out around 100 requests per second before queueing, even if the CPU is not busy.

Start with short timeouts, such as 1 second for connection and 2 to 5 seconds for reading a response, then tune to your SLO.
Retry only when the request is safe to repeat. Idempotent means repeating the same request does not create duplicates. That is why reads are easier to retry than writes.
Use exponential backoff, which means waiting longer after each retry, and add jitter, a small random delay, so many callers do not retry in the same instant.
For busy systems, use connection pooling so the client reuses TCP connections instead of paying the handshake cost for every call.
Watch for version drift: one service may deploy a new field while another still expects the old shape. Keep contracts backward compatible whenever possible.

Two failure types show up again and again: hard failures, such as a 404 or 500, and slow failures, such as a timeout. Slow failures are often worse because they do not fail fast; they consume threads, pile up requests, and cause a cascade. The fix is not only code, but also resilience patterns: timeouts, retries with limits, circuit breakers, bulkheads, and good observability with metrics, logs, and trace IDs.

package com.example.servicetocommunication; import java.util.Map; import org.springframework.beans.factory.annotation.Value; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.boot.web.client.RestTemplateBuilder; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.http.client.SimpleClientHttpRequestFactory; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import org.springframework.web.server.ResponseStatusException; import org.springframework.web.client.HttpClientErrorException; import org.springframework.web.client.HttpServerErrorException; import org.springframework.web.client.ResourceAccessException; import org.springframework.web.client.RestClientException; import org.springframework.web.client.RestTemplate; @SpringBootApplication public class ServiceToServiceCommunicationApplication { public static void main(String[] args) { SpringApplication.run(ServiceToServiceCommunicationApplication.class, args); } } @Configuration class HttpClientConfig { @Bean RestTemplate inventoryRestTemplate(RestTemplateBuilder builder, @Value("${service.inventory.base-url:http://localhost:8080}") String baseUrl) { // Fail fast: a slow downstream should not keep a servlet thread busy forever. SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory(); factory.setConnectTimeout(1_000); factory.setReadTimeout(2_000); return builder .rootUri(baseUrl) .requestFactory(() -> factory) .build(); } } record InventoryResponse(String sku, int available) {} record OrderResponse(String sku, String status, int remaining) {} @RestController @RequestMapping("/inventory") class InventoryController { // In the real world this would come from a database or cache. private final Map<String, Integer> stock = Map.of( "book-1", 5, "phone-2", 0, "laptop-9", 2 ); @GetMapping("/{sku}") public InventoryResponse getAvailability(@PathVariable String sku) { Integer available = stock.get(sku); if (available == null) { throw new ResponseStatusException(HttpStatus.NOT_FOUND, "Unknown SKU: " + sku); } return new InventoryResponse(sku, available); } @GetMapping("/slow/{sku}") public InventoryResponse slowAvailability(@PathVariable String sku) { try { // Simulate a dependency that is alive, but too slow for the timeout budget. Thread.sleep(3_000); } catch (InterruptedException ex) { Thread.currentThread().interrupt(); throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR, "Interrupted while simulating delay", ex); } Integer available = stock.get(sku); if (available == null) { throw new ResponseStatusException(HttpStatus.NOT_FOUND, "Unknown SKU: " + sku); } return new InventoryResponse(sku, available); } } @RestController @RequestMapping("/orders") class OrderController { private final RestTemplate inventoryRestTemplate; OrderController(RestTemplate inventoryRestTemplate) { this.inventoryRestTemplate = inventoryRestTemplate; } @PostMapping("/{sku}") public ResponseEntity<OrderResponse> placeOrder(@PathVariable String sku) { try { // This is the service-to-service call: Order asks Inventory before it creates anything. InventoryResponse inventory = inventoryRestTemplate.getForObject("/inventory/{sku}", InventoryResponse.class, sku); if (inventory == null) { throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "Inventory service returned no body"); } if (inventory.available() < 1) { throw new ResponseStatusException(HttpStatus.CONFLICT, "Item is out of stock"); } // In a real system you would now persist the order and probably reserve stock. return ResponseEntity.ok(new OrderResponse(sku, "CREATED", inventory.available() - 1)); } catch (HttpClientErrorException.NotFound ex) { // Translate a downstream 404 into a clean business error for the caller. throw new ResponseStatusException(HttpStatus.NOT_FOUND, "SKU not found in inventory", ex); } catch (HttpServerErrorException ex) { // Downstream 5xx should usually be treated as a temporary dependency failure. throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "Inventory service failed: " + ex.getStatusCode(), ex); } catch (ResourceAccessException ex) { // Timeouts and connection failures are common distributed-system failures. throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "Inventory service is unreachable or too slow", ex); } catch (RestClientException ex) { // Catch-all so unexpected client issues do not leak messy internals to the API boundary. throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "Unexpected inventory client failure", ex); } } @PostMapping("/slow/{sku}") public ResponseEntity<OrderResponse> placeOrderAgainstSlowInventory(@PathVariable String sku) { try { InventoryResponse inventory = inventoryRestTemplate.getForObject("/inventory/slow/{sku}", InventoryResponse.class, sku); if (inventory == null) { throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "Inventory service returned no body"); } if (inventory.available() < 1) { throw new ResponseStatusException(HttpStatus.CONFLICT, "Item is out of stock"); } return ResponseEntity.ok(new OrderResponse(sku, "CREATED", inventory.available() - 1)); } catch (ResourceAccessException ex) { // This demonstrates the failure path: the client times out instead of hanging forever. throw new ResponseStatusException(HttpStatus.SERVICE_UNAVAILABLE, "Request timed out while calling inventory", ex); } } }

Follow-up & Tricky Questions:

How do you choose between synchronous HTTP and messaging? Use synchronous HTTP when the user needs an answer now. Use messaging when the work can be delayed, when you want looser coupling, or when you need to survive a downstream outage without blocking the request path.
How do you secure service-to-service calls? Common options are JWT tokens, OAuth2 client credentials, or mTLS, which is mutual TLS where both sides prove their identity with certificates. In Spring Boot, the main goal is to send identity on every call and validate it at the edge of the receiving service.
How do you handle retries safely? Retry only transient failures and only for operations that can be repeated safely. For writes, use idempotency keys or a transaction pattern such as saga rather than blindly resending the request.
How do you observe calls across services? Propagate a trace ID or correlation ID in headers, log downstream status and latency, and export metrics such as error rate and p95 latency. That lets you follow one user request across multiple services.
When would you use OpenFeign? When you want a declarative HTTP client with less boilerplate. It improves readability, but it does not remove the need for timeouts, retries, and error handling.
Tricky: Is a 200 OK from the downstream always success? No. The transport may be successful while the business result is still a failure, such as a payload that says out of stock. Always check the domain data, not just the status code.
Tricky: Does a timeout prove the downstream did nothing? No. The remote service may have completed the work after your client gave up. That is why writes need idempotency and careful retry design.
Tricky: Can @Transactional span two services? No. A database transaction is local to one service and one database. Across services you need a saga, compensation steps, or a similar distributed workflow pattern.