You need Event Mesh, not Service Mesh
summary
Argues that an Event Mesh is the right pattern for microservices and shows a working Knative demo: legacy Java app publishes a CloudEvent, a Rust driver service consumes it and emits a driver-fee-calculated event back, and the legacy app updates the DB transactionally. Uses Knative Eventing with a broker configured for 10 retries and exponential backoff (~5 minutes total), uses CloudEvents for portability, autoscale-to-zero works, and the event-backed flow avoids cross-service transactional coupling.
AI-written summary · about
chapters (8)
- 0:00Event Mesh vs Service Mesh
- 2:38Transactional processing myth
- 7:15From transactions to eventual consistency
- 10:32Service mesh limitations
- 13:07Kubernetes and eventual consistency
- 19:20What is Event Mesh
- 23:21Demo: Event Mesh with KNative
- 44:00Key takeaways
related talks
26mService Mesh, Serverless and Event Drive
56mService Meshes - Powering the next wave of microservice architectures
43mWTF Do We Need a Service Mesh?
01h 03mJust what is a "service mesh", and if I get one will it make everything OK?
11mWelcome & Opening Remarks
35mAdvanced Microservices Architectures
17mGo event-driven with AWS Lambda & Event Mesh
47mEvent-Driven Microservices = Microservices Done Right