An event is a message representing something that has already happened in a system. In an event-driven architecture, services emit events and other services react to them instead of calling one another directly. section 13.2.2
A message carries the event’s data, often as JSON with timestamps, IDs, and topic names. Event logs reveal what the system communicated, when services consumed it, and whether processing was delayed, dropped, or dead-lettered. section 13.2.2
Use event logs to investigate questions such as:
- Was the event published, and which service published it? section 13.2.2
- Was it consumed, by whom, and when? section 13.2.2
- Can replaying the recorded event reproduce the failure safely in staging or testing? section 13.2.2
Missing welcome email
After users sign up successfully, inspect the UserRegistered event in Kafka. Confirm its publication and consumption, then replay it to test whether the email service reacts correctly. section 13.2.2
Figure 13.5 An event-driven design. A message broker manages the messages that are exchanged by several services.
Shows how a message broker connects services exchanging events. section 13.2.2
Figure 13.6 A developer can choose to replay events to troubleshoot a certain scenario.
Shows replay as a controlled troubleshooting action. section 13.2.2
