Patterns and practices for real-world event-driven microservices
summary
Jet.com runs roughly 700 microservices (est. 400–1,000), puts 90–95% of code in F# (90–95%), and runs on Azure with Kafka/SQL/Blob storage; event-driven and event-sourced architecture is core. Chaos engineering is mandatory, with controlled experiments to design for failure. Microservices are pure data-in/data-out scripts, side effects isolated, and replay uses a staged backup service. A homebuilt Torch lifecycle manager cuts deploys to ~30s and handles YAML-configured scaling.
AI-written summary · about
chapters (21)
- 0:00Intro
- 0:50Jetcom
- 3:55Microservices
- 6:40Chaos Engineering
- 10:38Definitions
- 13:18Event sourcing
- 15:46How did Jet decide on microservices
- 17:34Why did Jet choose Fsharp
- 22:58How Fsharp helped Jet
- 23:52Option types
- 31:14Perl not being readable
- 37:43Why Fsharp
- 37:57Shawns Fsharp talk
- 38:29Be functional
- 40:09Dont try abstract microservices
- 41:16Dont do this
- 41:48Separate them
- 42:21Staging
- 48:58Torch
- 51:07Summary
- 53:15More information
related talks
38mPatterns and Practices for Real-world event-driven microservices
26mImplementing Event-Driven Microservices Architecture (...)
48mChallenges in Implementing MicroServices
01h 07mMicroservices from the Trenches. A Guide through the Architecture, Design, Code
25mMaking microservices a behaviour not a buzzword
49mChallenges in Implementing Microservices
26mMicroservices
41m.NET Microservices in Real Life
