Service Oriented Architecture for Robust & Scalable Systems
summary
Claims that splitting a monolith into SOA makes teams and systems scalable and more maintainable, illustrated with concrete wins and failures: a 50‑dev codebase split, Yammer’s ~33 services and Twitter’s ~20 service breakdown, a five‑year sqlite removal that finally made deployments stateless, an API router and mobile API delivered. Tech choices: HTTP + JSON, queues, ESI/varnish, node proxy, OAuth, Puppet/Chef, AWS, Graylog/Logstash, PagerDuty. Patterns and cautions: circuit breaker, queues for backpressure, and the blunt takeaway timeouts are everything. Watch if you want practical patterns and real tradeoffs.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 8:34Why SOA is necessary
- 17:00Building robust SOA platform
- 30:26Defining service interfaces
- 41:30SOA challenges and pitfalls
- 44:44SOA real-world examples
- 49:24Summary
- 50:28Q&A
related talks
48mService Oriented Architecture - Slice and Dice
54mServices, Services, Everywhere!
57mSOA lessons learnt (OR Microservices done better)
52mSOA lessons learnt OR Microservices done better
26mBuilding Scalable Microservice APIs From The Beginning
40mFacing the Monolith Overcoming Monolithic Applications with SOA
40mService Architectures for Mere Mortals
34mSOA and the Monolithic Rails App Anti-Pattern