Bootstrapping Microservices • Ashley Davis & Damian Maclennan • GOTO 2024

Microservices should be right-sized for their purpose rather than arbitrarily small - focus on business domain boundaries and logical separation of concerns

Sharing databases between microservices is an anti-pattern that negates the benefits of microservices architecture by creating tight coupling

Start with a monolith first and extract microservices only when there is clear business value, like performance isolation, security boundaries, or team scalability needs

Having proper CI/CD automation, observability, and deployment pipelines in place is essential before attempting microservices - solve operational hygiene first

Local development experience and ability to test services independently is critical - developers should be able to run and debug services on their machines

Loose coupling between services and asynchronous communication patterns help prevent creating a distributed monolith with fragile dependencies

Microservices add complexity and overhead - only use them when their benefits (scalability, isolation, team autonomy) outweigh their costs

A hybrid approach with a mix of monoliths and targeted microservices is often more practical than going fully microservices

Technical debt is more manageable in microservices since it’s isolated to individual services that can be replaced

Consider performance-intensive or specialized workloads (AI/ML, video processing) as good candidates for separate microservices