request-reply-stream-talkingpoints.md

Introduce Heiko and stream topic

Welcome Heiko and explain to audience that he wrote the request/reply feature.

Introduce request/reply feature

• HEIKO will define what is request/reply.
• ALEJANDRA will show docs we have for request/reply and release notes (https://www.asyncapi.com/blog/release-notes-3.0.0#requestreply).

Explain request/reply top use cases to me like I'm a 5 year old.

1. Broker-based Messaging with Response Topic + "correlationId":

   • Your kid hate the birthday present you got them, so now you have to return online with a prepaid return sticker (the "response topic"). The return address on the sticker is the "topic". Your order number is the "correlationId".

2. Broker-based Messaging with Individual Inbox ("replyTopic") + "correlationId":

   • Imagine you and your friends have secret mailboxes (each one is a "replyTopic") for receiving letters. When you send a letter, you tell them which secret mailbox to send the reply to. Again, each letter has a special sticker ("correlationId") to match letters and replies.

3. Broker-based Messaging with a Temporary Reply Topic for an Individual Response:

   • It's like creating a pop-up mailbox (a "temporary reply topic") each time you send a letter. Your friend sends the reply to this pop-up mailbox, and after you get the reply, the mailbox disappears.

Dig deeper into request/reply

AsyncAPI Specification 3.0.0, with its new features including request/reply patterns, is designed to enhance asynchronous communication in APIs:

1. Broker-based Messaging with Well-defined Response Topic + "correlationId":

   • Use Case: In this scenario, messages are sent through a broker (like Kafka, RabbitMQ, etc.) to a specific topic. Each message can have a "correlationId" that uniquely identifies it.
   • How It Works: When a message is published to a topic, the response to this message is sent to a pre-defined response topic. The "correlationId" helps in matching the response with the original request, ensuring that the response is correctly associated with its request.
   • AsyncAPI Specification Role: The AsyncAPI document would define the request topic, the response topic, and the schema for the "correlationId", providing a clear contract for how messages and their responses are to be handled.

2. Broker-based Messaging with Per Process Individual Inbox aka "replyTopic" + "correlationId":

   • Use Case: Similar to the first, but instead of a well-defined response topic, each process (or service) has its own individual inbox (replyTopic) for responses.
   • How It Works: When a request is sent, the "replyTopic" is specified (often unique to the requester), and the response is sent to this specific topic. The "correlationId" still plays a crucial role in linking responses to requests.
   • AsyncAPI Specification Role: AsyncAPI will document how the "replyTopic" is determined and used, along with the "correlationId" usage. Such a setup is useful for ensuring that responses are directed to the correct requester in systems with many services.

3. Broker-based Messaging with a Temporary Reply Topic for an Individual Response:

   • Use Case: In this pattern, a temporary topic is created for each request's response.
   • How It Works: The requester creates a temporary topic (often with a unique name) and sends this along with the request. The responder sends the reply to this temporary topic, which is then discarded after use.
   • AsyncAPI Specification Role: The specification would describe the creation and usage of these temporary topics and the lifecycle of messages, ensuring that anyone using the API understands the temporary nature of the response mechanism.