independent deployability, independent scalability, ease of refactoring, reduced blast radius, code ownership and maintenance, rapid iteration, language diversi

independent deployability, independent scalability, ease of refactoring, reduced blast radius, code ownership and maintenance, rapid iteration, language diversity (ie an ml service in python and a rest api in nodejs), clear domain (payments, user management, data repository and search) just to name a few. if two or more services need none of the above or must communicate with the same database or is too complex to communicate with each other if a db is not used (ie queue nightmare, shared cache or files) are usually signs that the two should be merged as they probably belong to the same domain. at least thats some of the logic i follow when architecting them.