REJECTED
2024-11-15
Three months after completing the microservices migration (ADR-019), several engineers have raised concerns about the increased operational complexity. A Slack thread titled "Maybe we should just go back to the monolith" gained significant traction, with 47 emoji reactions and a heated discussion spanning 200+ messages.
- On-call Burden: Incidents now require understanding multiple services
- Debugging Complexity: Simple issues take longer to diagnose
- Deployment Coordination: Despite "independent" deployments, changes often span services
- Infrastructure Costs: Running 5 services costs more than 1 monolith
- Cognitive Load: New engineers take longer to understand the system
- Mean Time to Resolution (MTTR) increased from 15 minutes to 45 minutes
- On-call pages increased 40% since migration
- New engineer onboarding time increased from 1 week to 3 weeks
- Monthly infrastructure costs increased 65%
"We took a simple problem and made it complicated for no reason." - Senior Engineer A
"I've spent more time debugging Kafka consumer lag than writing actual FizzBuzz code." - Senior Engineer B
"The monolith was fine. It handled our load. Why did we fix something that wasn't broken?" - Principal Engineer
After careful consideration, this proposal is REJECTED.
While the concerns raised are valid and the data is real, reverting to a monolith would:
- Waste Previous Investment: 6+ engineer-months went into the migration
- Create Another Migration: We'd need another multi-month project to consolidate
- Not Address Root Causes: Many issues are due to immature tooling, not architecture
- Limit Future Growth: We have concrete plans for Bazz (divisibility by 7) that microservices enable
Instead of reverting, we will invest in improving our microservices operations:
| Concern | Mitigation |
|---|---|
| On-call burden | Improve runbooks, implement better alerting |
| Debugging | Deploy OpenTelemetry distributed tracing |
| Deployment coordination | Implement contract testing |
| Infrastructure costs | Optimize resource allocation, use spot instances |
| Cognitive load | Better documentation, architecture diagrams |
- ADR-025: Implementing OpenTelemetry (COMPLETED)
- ADR-026: Contract Testing Strategy (IN PROGRESS)
- Runbook improvements (see docs/runbooks/)
- Architecture documentation refresh
- Would require 4-6 months to consolidate services
- Would lose ability to scale Fizz/Buzz independently
- Would create deployment coupling between teams
- Would set precedent that architectural decisions can be easily reversed
- Teams continue to operate microservices
- Investment in observability and tooling
- Potential for lingering resentment among engineers who supported reverting
- Need to demonstrate improved metrics within 6 months
This section captures significant disagreement with the decision.
Senior Engineer B:
I respectfully disagree. The 'immature tooling' argument has been used to justify every microservices project I've worked on. The tooling never matures fast enough, and we're always chasing the complexity we created. I'll comply with the decision but want my objection on record.
Principal Engineer:
I've seen this movie before. We'll spend the next year 'improving our microservices operations' and end up with the same problems plus more infrastructure. I predict we'll revisit this ADR within 18 months.
- ADR-019: Migration from Monolith to Microservices
- Slack thread: #engineering-general "Maybe we should just go back to the monolith"
- Microservices: Please, don't (external)
- MonolithFirst by Martin Fowler
- 2024-11-15: Proposed
- 2024-11-22: Reviewed in Architecture Review Board
- 2024-11-25: REJECTED after ARB vote (4-3)
Note: This ADR documents a rejected proposal. For the current architectural direction, see ADR-019 and ADR-041.