Service Oriented Disasters
summary
Three concrete case studies: extracting a votable hats service fails to be independent because it connects to the old DB and reuses tangled hat models, packaged as a gem and backed out before production; an identity service without its own database that creates a hard coupling and a single point of failure so both apps must stay up and scaling worsens (example numbers: 2,000 main servers vs 100 auth servers); and a successful pattern: dark‑launching rewrites with GitHub’s Scientist to compare old and new paths in production.
AI-written summary · about
chapters (6)
- 0:00Start
- 0:41bit.ly/ service oriented disasters
- 2:321. Make each class and method conceptually simple.
- 9:09Problems to solve: 1. Follow Single Respon
- 15:17Case Study 2: An Identity Service
- 20:56Case Study 3: Sharing Assets Across Application
related talks
30mService Oriented Design in Practice
01h 00mService Oriented Architecture for Robust & Scalable Systems
39mStop Building Services, Episode 1: The Phantom Menace
54mServices, Services, Everywhere!
36mAn Iterative Approach to Service Oriented Architecture
35mMicroservices: A Tale of 3 Heroes
39m10 Tips for failing at microservices
41mMe, My Organization and My-croservices
