Can Time-Travel Keep You From Blowing Up The Enterprise?
summary
Argues that the right move is not monolith vs microservices but evolving architecture: adopt rule of three to create generators and gems, prefer one Rails app per business function, keep business logic out of ActiveRecord, and add a message bus via CloudAMQP RabbitMQ to sync caches. Describes building a backend‑for‑frontends, one promo‑code HTTP service (it works), and tooling that makes the fourth app cheap so the Enterprise stops blowing up.
AI-written summary · about
chapters (4)
related talks
32mRefactoring Legacy Apps with APIs and Messages
40mService Architectures for Mere Mortals
55mArchitectural Patterns for Rapid, Reliable, Frequent and Sustainable Development
27mScaling a Rails Monolith w/Event Driven Microservices
57mForking the Future: Embracing Microservices Evolution
48mIT Architecture : All your micro-services are wrong PERIOD!
36mDo Proper Monoliths before You Do Microservices!
37mArchitecture: The Next Generation