Chapter II · Area 07 of 12

Communication & APIs

The Question for Our ShopMust checkout wait until the invoice PDF is ready?

Here you will learn how system parts exchange data and work together reliably.

Three questions for every collaboration

  1. What is promised, and who gets in?

    Contracts & access

    Warehouse promises reservation R-77 for B-1042; the field expiresAt is added in a compatible way.

  2. Does the caller wait for a response?

    Temporal coupling

    Order asks warehouse directly; invoice accepts the job, OrderPaid goes to shipping and analytics.

  3. What happens on retries and failures?

    Reliability

    pay-B-1042 prevents double charging; the outbox holds OrderConfirmed until the channel is reachable again.

This is how the building blocks hang together

API contracts define the commitments. Synchronous and asynchronous communication use them, queues and pub/sub distribute messages. Idempotency secures retries, the outbox secures publication, orchestration runs processes. The gateway controls access, versioning controls evolution.

ConceptAPI contractsAPI contracts define data, meaning and observable interface behavior as binding rules.PatternSynchronous communicationuses API contracts for responses, errors and timing behaviourPatternAsynchronous communicationuses API contracts for message structure, meaning and statesConceptIdempotencykeeps the business effect stable when the same job is repeatedDecision spaceQueues, Pub/Sub & Streamsdistribute messages whose form and meaning are defined by the contractMechanismAPI versioningevolves contracts with clear compatibility and migration rulesPatternTransactional Outboxpublishes events whose form and meaning are defined by the contractDecision spaceOrchestration & choreographycontrols processes via interfaces whose commitments are defined by the contractPattern familyGateway, Mesh & Discoveryroutes external requests according to the commitments of the contract
Relations: Synchronous communication uses API contracts for responses, errors and timing behaviour; Asynchronous communication uses API contracts for message structure, meaning and states; Idempotency keeps the business effect stable when the same job is repeated; Queues, Pub/Sub & Streams distribute messages whose form and meaning are defined by the contract; API versioning evolves contracts with clear compatibility and migration rules; Transactional Outbox publishes events whose form and meaning are defined by the contract; Orchestration & choreography controls processes via interfaces whose commitments are defined by the contract; Gateway, Mesh & Discovery routes external requests according to the commitments of the contract.

Your learning path through the area

Here you clarify whether checkout has to wait for the invoice, what callers are promised and how retries and changes stay reliable. Each building block shows its theme at our shop.

  1. This is what you learnYou can name mandatory fields, results and errors of a storage reservation as a contract.

    In the shopOrder reserved on the contract of the storage module two cups for B-1042. The reservation has a stable identifier and an expiration date.

    API contracts Open
  2. Synchronous communication

    Temporal coupling

    This is what you learnIn the checkout, you can mark which calls the order process immediately awaits a response.

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

    Synchronous communication Open
  3. This is what you learnYou can separate acceptance, later processing and visible status of an invoice order.

    In the shopAfter confirmed order, invoice accepts an order and creates the receipt later. The checkout does not have to wait for the finished PDF.

    Asynchronous communication Open
  4. Queues, Pub/Sub & Streams

    Temporal coupling

    This is what you learnYou can assign queue, pub/sub and stream for three specific shop tasks.

    In the shopThe shop processes invoice orders, distributes orderPaid for shipping and analysis and keeps order status changes for later evaluation.

    Queues, Pub/Sub & Streams Open
  5. Idempotency

    Reliability

    This is what you learnYou can predict when repeated calls will trigger the same or a new business impact.

    In the shopThe payment module sends B-1042 with the key pay-B-1042 to the external provider. The first answer is lost.

    Idempotency Open
  6. This is what you learnYou can show how the order and the publishing order are stored together and later shipped separately.

    In the shopVariant with permanent news channel: order confirmed B-1042 and at the same time stores order confirmed in your outbox. The news channel is temporarily unreachable.

    Transactional Outbox Open
  7. This is what you learnFor reservation and payment, you can distinguish between orchestration and choreography.

    In the shopVariant: Warehouse and payment are independent services. The team compares an order orchestration with an event-driven choreography; the payment provider remains external.

    Orchestration & choreography Open
  8. This is what you learnYou can assign external shop routes to the relevant internal destinations via an API gateway.

    In the shopVariant: Catalogue and shipping were separated as services for proven operational reasons. Browser and customer service access shop routes exclusively via the API gateway.

    Gateway, Mesh & Discovery Open
  9. This is what you learnYou can distinguish a compatible API extension from a breaking meaning change.

    In the shopThe warehouse module extends the reservation response with expiresAt. Later, the existing field available should change from a number to a business availability level.

    API versioning Open
Afterwards in the learning path · area 08Distributed systems