Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

PatternChapter II · Communication · Building block 2 of 9

Synchronous communication

Synchronous communication couples a request in time to its response. The caller waits until the result, error or end of his waiting period.

By Michael Meierhoff · Meierhoff Systems

  1. Waiting pathAll the calls that are waiting for.
  2. Availability multiplied byAny dependence reduces the overall result.
  3. TimeoutLimits waiting in case of failure.

Context

Why this is important

Those who call in sync are waiting. Waiting times add up, availabilities multiply: every dependency in the checkout extends the waiting path and can block it in the event of failure. Temporally decoupled processing handles asynchronous communication.

This building block explains immediate request-response relationships. For later processing, see Asynchronous Communication.

At a glance · call with waiting for answer

The client calls service A, which in turn calls service B; everyone waits until the response comes back.
Shop example · Waiting chain

Waiting Chain in Checkout

In modular monoliths, ordering requests warehouse and payment directly. The payment module calls the external payment provider via the network.

This is how you read the picture

  1. Waiting path The switched-on calls; their milliseconds result in the waiting time.
  2. Availability multiplied by The availability of the checkout decreases with each connected call.
  3. Timeout If the provider is unsuccessful, the order waits until 3000 ms.

OrderWaiting for

Waiting time of the checkout
450 ms
Availability of checkout
99.30 %

Waiting times add up, availabilities multiply: each connected call makes the checkout slower and less available.

Times and Availabilities illustrative

Switch calls on or off and let the payment provider down; times and availability are illustrative.

Benefits & limitations

Helps if:

  • A request-response interaction returns the result the caller needs for their next step.
  • An immediate business feedback can be returned directly with synchronous communication.
  • Controlled time budgets bound waiting; a response within budget supplies the result needed for the next step.

Boundaries

  • Each additional synchronous dependency extends the waiting path and reduces the overall availability of the checkout.
  • After a timeout, the other party may already have performed the operation. Timeout bounds waiting; Retry controls further attempts.
  • A failed external provider blocks the caller until the end of the waiting period, even if all internal modules are running.

In practice

  1. Distribute the time budget across all synchronous dependencies and set a clear response limit. This leaves a verifiable maximum waiting time for the entire interaction.
  2. Differentiate business rejection, transport error and timeout in the contract. The caller can then appropriately cancel, ask or display a status.
  3. Retry only operations with safe semantics and a limited attempt count. Timeout covers waiting limits; Retry governs repeated calls.
Read the detailed explanation

In synchronous communication, the caller waits for a response or a defined time limit. The result can feed directly into the current process. The other party's latency and failures therefore affect the caller immediately.

Timeouts establish only that no timely response arrived, not the business outcome. Time budgets, error responses and permitted retries are part of the contract. Long synchronous chains add waiting time and couple availability across components.

Timeout limits waiting but does not establish whether a commit occurred; Retry therefore requires safe retry semantics.

REST over HTTP and gRPC are common forms of synchronous calls. Both need timeouts to prevent indefinite waiting.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    How do waiting times and availability change when the invoice is switched on?

    View the solution with justification

    The waiting time increases from 450 on 1250 ms, the availability decreases by about 99,3 at approximately 98,8 Percent (illustrative values).

  2. ApplyingTransferred to a new situation

    The payment provider fails. What happens to the checkout?

    View the solution with justification

    Payment waits for the provider, order for payment. The checkout is up until the timeout 3000 MS and then fails.

  3. EvaluateWeighing an alternative

    Should the PDF generation of the invoice remain in the synchronous checkout?

    View the solution with justification

    Advantage: The document is available immediately. Disadvantage: 800 ms more waiting time and a failure risk more. Recommendation: generate asynchronously, the checkout does not need the receipt for confirmation.

Explore further

These building blocks continue the thoughts of this page.

CommunicationAsynchronous communicationAsynchronous communication accepts work and enables it to be processed later.Opening OperationsTimeoutA timeout limits waiting time. Here you learn how the caller handles the resulting state.Opening CommunicationAPI contractsAPI contracts define data, meaning and observable interface behavior as binding rules.Opening

References

Continue on the learning path

Next in Communication & APIs: Asynchronous communication.

9 Building blocks

Continue withAsynchronous communication