On what criteria should a monolith be decomposed into microservices?

Decomposition of a monolith into microservices should be based on several key criteria:

1. Bounded Contexts: Separation by business domains so that each microservice is responsible for a specific context and business logic.

2. Data Isolation: Each service should have its own database or schema to avoid tight coupling through shared data.

3. Deployment Independence: Microservices should be autonomous to allow independent updates and scaling.

4. Change Frequency: Components that change frequently are better isolated into separate services to minimize impact on the rest of the system.

5. Team Structure: The organization of teams can influence service boundaries (Conway's Law).

6. Technical Requirements: Different performance, scalability, or technology requirements may dictate separation.

7. Interaction and Dependencies: Services with minimal dependencies on each other are more suitable for a microservices architecture.

8. Monitoring and Error Management: Microservices should be small enough to effectively track and localize issues.

It is important to remember that decomposition is an iterative process, and initially, large services can be identified and gradually broken down as the system grows and requirements become clearer.