A humble suggestion to anybody contemplating a greenfield microservices architecture, especially if you're replacing a monolithic "big ball of mud" that has become hard to work with ... *draw some diagrams showing your proposed design*.
Take something like my C4 model (c4model.com) and create the first two levels; System Context and Containers. Treat each microservice and any data stores as separate containers. Here's a simple example -> structurizr.com/share/4241#Con…
Draw the inter-service relationships too. Be sure to include information about the technologies you're planning to use (both for the services and the inter-service communication), and also the responsibilities of each service.
If this diagram starts to get complicated, well, it's probably mirroring the real world. Have a long hard think about whether you really need as many services. Use this diagram to identify any single points of failure. Also look for any pinch points or bottlenecks.
Now, take some of the key use cases/scenarios/stories/features and dry-run them across your diagram. Keep an eye out for long chains of synchronously coupled service calls, and temporal coupling in general.
There are lots of other things to look for too (e.g. lock-stepped deployment, service ownership, shared code, deployment, operational concerns, etc). Building a distributed architecture is hard. A few hours thinking could save you a whole lot of pain and misery later.
