Service-to-Service Communication.

Hook: In microservices, one service often has to call another before it can finish the user’s request — and that is exactly where slowdowns, outages, and bad retry logic hide.

Question: What is service-to-service communication in Spring Boot?

Answer: Service-to-service communication is when one Spring Boot microservice sends data to another microservice to complete a task. The most common form is a request/response HTTP call, but it can also be asynchronous with messages like Kafka events. The key idea is that the caller should set timeouts, handle errors, and keep the call small and focused.

Interview-Ready Answer: I think of service-to-service communication as one microservice depending on another to finish a business step. In Spring Boot, I would usually use RestClient, WebClient, or a declarative client like OpenFeign for HTTP calls, and I would set short timeouts, handle 4xx and 5xx responses explicitly, and add retries only for safe, idempotent reads. If the work is long-running or can be decoupled, I would prefer messaging like Kafka so one slow service does not block the whole request path.

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

1. The caller receives a request and decides it needs data from another service.
2. 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.
3. The HTTP client opens or reuses a TCP connection. If TLS is enabled, the client also negotiates encrypted transport before sending business data.
4. The caller sends the request plus headers such as authorization and a correlation ID, which is a shared tracking value for one user flow.
5. The downstream service processes the request, hits its own database or cache, and returns success or an error code like 404, 409, or 503.
6. 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.
7. 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

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.

Real-world story

Imagine an e-commerce checkout service. Before it creates an order, it calls an inventory service to make sure the item is in stock, and it may also call pricing and shipping services. This is normal service-to-service communication: the checkout service owns the user flow, but it depends on other services for facts it does not own.

Now picture a bug: inventory becomes slow because its database index is missing after a deploy. Checkout keeps making synchronous HTTP calls with no timeout. Threads pile up, requests wait, and the site starts showing spinning loaders. In logs you see messages like Read timed out or 503 Service Unavailable, and in metrics the p95 latency jumps from 120 ms to several seconds. Users cannot finish payment even though the checkout code itself did not crash — it is stuck waiting on a dependency.

The fix is to fail fast, return a useful error, and decide whether a fallback is safe. For stock checks, a clear 503 is often better than letting the page hang forever. For email notifications, a queue would be better than a direct call because the user does not need to wait.

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.

Common Mistakes:

• Hard-coding service URLs. Correction: keep base URLs in configuration or use service discovery so environments can change without code changes.
• No timeout at all. Correction: always set connect and read timeouts so one bad dependency cannot pin all threads.
• Retrying every failure. Correction: retry only transient errors, limit the number of attempts, and use backoff plus jitter to avoid a retry storm.
• Ignoring business meaning. Correction: inspect the response body and domain rules, not just the HTTP status, because a 200 response can still represent a failed business action.

Memory Hook: Think phone call vs mailbox: synchronous service-to-service communication is a phone call, so both sides must stay online at the same time; asynchronous messaging is a mailbox, so the sender can drop the message and keep going.

Cheat Sheet:

• Service-to-service communication = one microservice depends on another during a business flow.
• Use synchronous HTTP for immediate answers; use messaging for decoupled or slow work.
• Set timeouts, handle 4xx/5xx separately, and retry only safe operations.
• Blocking calls consume threads; non-blocking calls scale better under high concurrency.
• Make requests observable with trace IDs, logs, and metrics.
• Prefer backward-compatible contracts so one deployment does not break another.

Practice Tasks:

• Add a new endpoint that calls the inventory service twice and compare the total latency with one call.
• Replace the RestTemplate example with WebClient or RestClient and keep the same error handling behavior.
• Add a correlation ID header and print it in both controllers so you can trace one request end to end.