I was recently asked about considerations while migrating to microservices architecture. While I believe not every company needs microservices, they can be really useful in scaling your org and systems.

Here are some of the top things I would keep in mind:

1. Abstraction - how well a problem is abstracted so that it doesn’t leak its core business rules to other services, at the same time does only one or two things.
2. Independent DB(s) - doesn’t share its database with other microservices. One micro-service, however, definitely can use multiple databases.
3. Latency and number of microservices that hit in a flow - this should ideally be limited to a specific number. P95, P99 latency, and error rates should be tracked and monitored.
4. DAG - there’s no circular dependency, and the relationship between microservices is ‘Directed Acyclic Graph’. This will keep dependencies, latencies, and complexity in check.
5. Classification between core and auxiliary services - the idea is if any of the auxiliary services die, users should face a degraded experience but no downtime.
6. SDK - build SDK that microservices can use to call other microservices. The idea is that this SDK becomes a core library with its inbuilt logic around logging metrics and handling degraded behavior (constructs like circuit breakers)
7. Platform Services & Modules - in addition, a lot of duplicated code across microservices should be pulled out and abstracted either as a supporting service or library (ex. locking, scheduler - no business logic though, connection pooling, throttling, analytics logger)
8. Team - take into consideration how your org structure would evolve in the next 2-3 years, the kind of product and platform teams you would have, and ensure no microservice is shared between teams.