You Keep Using That Word: Asynchronous And Interprocess Comms
summary
Argues that “asynchronous” is too vague and should be replaced by concrete terms and patterns, claiming no consistent definition exists. Distinguishes request–response vs event-driven, highlights latency math (50 ms + 150 ms = 200 ms sequential vs 150 ms parallel) and shows value of non-blocking futures and reactive extensions. Recommends temporal decoupling via an intermediary like a message broker (RabbitMQ, Kafka), notes need for correlation IDs and stateless response handling, and warns non‑blocking alone does not solve waiting for results.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:09Talk purpose
- 4:00Sync vs async confusion
- 8:38Problems with async term
- 13:28Defining async
- 18:04Non-blocking latency
- 26:59Temporal decoupling
- 33:34Request response brokers
- 37:51Stateless failure handling
- 41:03Technical terminology context
- 45:24Socio-technical systems
- 49:55Async term useless
- 50:15Practical alternatives
- 52:29Q&A
related talks
52mYou Keep Using That Word: Asynchronous And Interprocess Comms
49mYou Keep Using That Word: Asynchronous And Interprocess Comms (Remote)
01h 01mYou Keep Using That Word: Asynchronous And Interprocess Comms
38mYou Keep Using That Word
42mYou Keep Using That Word
01h 01mThe Unsung Hero of Modern Software: Asynchronous Messaging
47mEverything Loosely Coupled - Advanced Integration Patterns and Their Trade-Offs
44mFrom Synchronous to Asynchronous Distributed Microservices
