You’re reading the free preview.Unlock every conversation for €2.99
FreeFree previewChapter 8
Chapter 8 · Free preview
Beyond Request-Response
When Waiting Becomes the Problem
What you will understand
- Explain the difference between synchronous and asynchronous processing
- Describe when to use a message broker instead of direct API calls
- Explain the difference between a queue and a topic
- Describe caching strategies and know when to invalidate the cache
- Explain what idempotency is and why it matters in message processing
Written by EduVerse for this preview; the slides below are the book’s own words.
Slides from the chapter
Each slide is a passage from the book with the figure or listing it talks about. Swipe, use the arrow keys or the buttons.
Slide 1 of 4
Beyond Request-Response
p. 181
Conversation from The Software Realm, Decoded
Chapter 8 · Beyond Request-Response · p. 181
Senior developer
The email takes 2 seconds because it calls an external SMTP server. Does the user really need to wait for it?
Peter
No... the email can arrive a few seconds or even minutes later. But how do I send it without waiting?
Senior developer
This is where asynchronous systems come in. Instead of doing the work yourself, you announce ’Order Placed’ to a message broker. Other services listen for that announcement and handle their tasks in the background.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 8 · Beyond Request-Response · p. 181
Senior developer looks at the flow:
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (8)
Description
Flow diagram: from User clicks 'Place Order', arrows lead top to bottom through 'Save to Database (50ms)', a red 'Send Email (2000ms)' step marked 'SLOW!', 'Update Inventory (100ms)' and 'Return Response'. A note beside it reads 'Problem: User waits 2,150ms. Everything is sequential.'
Description written by EduVerse; the figure itself is from the book.
Synchronous vs. Asynchronous: The Core Difference
8.1 · p. 182
Conversation from The Software Realm, Decoded
Chapter 8 · 8.1 Synchronous vs. Asynchronous: The Core Difference · p. 182
Peter
So the waiter drops off the order and immediately helps other customers? The bell is like an event notification?
Senior developer
Exactly. In code, the bell is the message broker. The order ticket is the event. The waiter doesn’t stand around waiting, he’s free to do other work.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 8 · 8.1 Synchronous vs. Asynchronous: The Core Difference · p. 182
The waiter drops the order and immediately helps other customers. A bell signals when food is ready.
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (7)
Description
Diagram: an arrow runs from 'Table 1' to the 'Waiter' and grey arrows from the waiter to 'Table 2' and 'Table 3'; the waiter sends 'Drop ticket' to the 'Kitchen', and a star labelled 'Bell' signals back to the waiter with 'Ding!'. The note reads 'Benefit: Waiter serves 3 tables while kitchen cooks. Bell (event) signals when food is ready.'
Description written by EduVerse; the figure itself is from the book.
Kafka vs. RabbitMQ: Recording vs. Mailbox
8.4 · p. 189
Conversation from The Software Realm, Decoded
Chapter 8 · 8.4 Kafka vs. RabbitMQ: Recording vs. Mailbox · p. 189
Peter
I keep hearing about Kafka and RabbitMQ. What’s the difference?
Senior developer
Great question. They both deliver messages, but they work fundamentally differently. Think of RabbitMQ as a mailbox. Kafka as a recording.
What the book shows with it
Figure from The Software Realm, Decoded
Chapter 8 · 8.4.1 RabbitMQ: The Mailbox · p. 189
Mental Model: Your mailbox. Letter arrives → You take it → It’s gone from the mailbox.
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (2)
Description
Diagram: a 'RabbitMQ' box holding 'Letter 1', 'Letter 2' and 'Letter 3' has a red 'Take letter' arrow to a 'Consumer'. The note says a message is a task to complete, is deleted once the consumer takes it and old messages cannot be replayed; 'Use: Job processing (resize image, send email)'.
Description written by EduVerse; the figure itself is from the book.
Kafka: The Recording
8.4.2 · pp. 189–190
Figure from The Software Realm, Decoded
Chapter 8 · 8.4.2 Kafka: The Recording · pp. 189–190
Mental Model: A DVR recording. Show airs at 8pm → It’s recorded → You can watch it now, tomorrow, or next week. Others can watch it too.
Explore this figure
Pick one to highlight it and read what the book says about it.
Other labels in the figure (12)
Description
Diagram: 'Kafka (Event Log)' lists orders 123 to 126 timed 12:00 to 12:03 and is 'Kept for 7 days'; arrows lead to 'Consumer 1' and 'Consumer 3' 'from 12:00' and to 'Consumer 2' 'from 12:02'. The note says events are kept for days, consumers read independently and can replay from any point; 'Use: Event-driven architecture, audit trails'.
Description written by EduVerse; the figure itself is from the book.
Slide 1 of 4
Try it yourself
A simulation built by EduVerse around this chapter. It runs in your browser; nothing is sent anywhere.
The full chapter
This preview shows 7 of the chapter’s 43 passages. The full chapter has:
- 8 sections
- 22 conversations
- 22 figures and tables
- 1 What They Say boxes
- 7 knowledge-check questions
Sections in this chapter
- 8.1Synchronous vs. Asynchronous: The Core Difference
- 8.2Message Brokers: When Services Stop Calling Each Other
- 8.3Queues vs. Topics: Two Delivery Patterns
- 8.4Kafka vs. RabbitMQ: Recording vs. Mailbox
- 8.5Redis: The Speed Layer
- 8.6Idempotency: Handling Duplicate Messages
- 8.7Failure Handling: When Things Break
- 8.8Peter's Takeaways