Monolith-ifying perfectly good microservices
summary
Intercom consolidates several standalone services back into its Rails monolith and reports concrete wins: reduced operational toil, faster feature delivery, and fewer outages. Specific moves include rewrote user and company storage, swapped MongoDB for DynamoDB, and ported the Java webhooks service into the monolith using SQS-backed workers, plus Rack::Attack and route tuning for the copied Help Center code. The app runs ~50k Rails processes on ~1k EC2 hosts, serves ~600M messages/month, and the migrations restore developer productivity.
AI-written summary · about
chapters (9)
- 0:00Introduction and journey
- 3:14Intercom’s Rails monolith today
- 6:42Three acts of architecture
- 8:25Act two: Confrontation
- 16:56Act three: Resolution
- 21:55Monolith-ifying web hooks
- 24:21Porting the Help Center
- 26:07Stopped building outside monolith
- 27:32Lessons learned
related talks
26mMonolith-ifying perfectly good microservices
21mTaming Monoliths Without Microservices
27mFrom multiple apps to Monolith
39mTaming Monoliths Without Microservices
27mScaling a Rails Monolith w/Event Driven Microservices
33mAdventures with Micro Services in Rails
56mFrom Homogeneous Monolith to Heterogeneous Microservices Architecture
48mMicroMonolith