Patterns and Practices for Real-world event-driven microservices
summary
Jet.com designs an event‑driven platform with 300–350 microservices, processes ~20,000 orders/day (growth from hundreds), and relies on Azure and F# while embracing event sourcing and immutable data. Key concrete practices: isolate side effects, use a staging backup service to replay events, one YAML per service for runtime config, and a homegrown runtime Torch: 30s deploy that cuts deployment from ~15–20 minutes. These practices prove practical and repeatable in production.
AI-written summary · about
chapters (12)
- 0:00Intro
- 0:33Taking on Amazon!
- 5:51Does anyone here use Rx?
- 6:36Event-sourced
- 9:33Don't abstract
- 10:46Be functional!
- 13:18Isolate side effects
- 15:14Use a backup service to replay events
- 17:00What do our services look like?
- 24:23Microservices should not control own lifecycle
- 27:23Torch YAML files
- 29:31Summary
related talks
55mPatterns and practices for real-world event-driven microservices
26mImplementing Event-Driven Microservices Architecture (...)
01h 07mMicroservices from the Trenches. A Guide through the Architecture, Design, Code
01h 08mEvent Driven Architecture – Enabling Microservices
45mMicroservices: A retrospective
48mChallenges in Implementing MicroServices
41m.NET Microservices in Real Life
58mMicroservices at Scale - ASP.NET Core, Service Fabric, and Azure in production
