We split our monolith into 15 microservices in 3 months. Then spent 2 years fixing the boundaries.

How we split:

  • One service per database table
  • "That seems like a natural boundary"
  • Ship fast, fix later

What we got wrong:

  • Order service needed Customer data
  • Customer service needed Order history
  • Every request: 5+ inter-service calls
  • Distributed joins via HTTP (yes, really)

The symptoms:

  • P99 latency: 50ms → 800ms
  • One service down = everything broken
  • Teams couldn't release independently (the whole point)
  • Data inconsistency between services

What we should have done:

  • DDD event storming first
  • Find actual bounded contexts
  • Split by business capability, not table
  • Validate boundaries with traffic patterns

Lesson: Service boundaries are the hardest thing to get right. Take your time — boundary design is exactly where an outside DevOps and architecture review pays for itself before the split, not after.

← Back to Lessons Learned

Incidents like this are preventable. Our AWS Managed Services team watches client environments 24/7 with AI-assisted monitoring and senior engineers on the pager — so stories like this stay in the archive.

Tags: #Microservices #Monolith #Migration #Architecture