Microservices from the Trenches. When Buzzwords Don't Make Your Application Work
summary
Rebuild of a time-and-attendance system for contact centres uses .NET, a single real bounded context (timesheet) plus several small CRUD support services (account, employee, timepunch). Communication relies on RabbitMQ and starts with a fan-out pattern, exposing lost performance and leading to exchange/queue segmentation and optional transactional store-then-publish semantics. An Ocelot API Gateway handles service discovery, header transformation and auth. Result: it works but operational complexity outweighs benefits for this small domain.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 2:14What was the project
- 3:37What is a microservice
- 4:16What does small mean
- 7:16Benefits of Microservices
- 9:55About the project
- 12:52The first challenge
- 21:54Conclusion
- 27:14Messaging
- 28:57Messaging Models
- 30:40Message Brokers
- 35:42Message Libraries
- 41:52API Gateway
- 46:12Other API Gateways
- 46:59The Solution
related talks
56mMicroservices from the trenches
01h 01mMicroservices Gone Wrong
41m.NET Microservices in Real Life
10mMicroservices, Messaging, and Failure: How Simplifying Our Architecture Saved Us
03mMicroServices - Let’s Build Some!
46mMicroservices from the Trenches
22mMicroservices Highway to hell
01h 07mMicroservices from the Trenches. A Guide through the Architecture, Design, Code
