Working on an API...Consider an example database like the following for some enterprise-facing application:+-------------------------------+|            tables             |+-------------------------------+| account_achievement_mappings  || account_company_mappings      || account_document_mappings     || account_feature_mappings      || account_group_mappings        || account_notification_mappings || accounts                      || achievements                  || companies                     || company_document_mappings     || company_feature_mappings      || documents                     || features                      || group_company_mappings        || group_document_mappings       || group_feature_mappings        || groups                        || notifications                 |+-------------------------------+None of the tables are too complicated, and they are relationships can be pretty well inferred from their names.As I understand, with a micro service architecture, each micro service should have its own database.I am wondering if it is possible to break up such a schema into sub-schemas, so that it can then refactored from a monolith to a collection of micro services.For example, since notifications are only linked to accounts I though that pulling that out and creating a notification engine might be a good first candidate.Edit:1) If micro services share a database, wouldn't the database become a bottleneck? 2) If I can separate my database into a set of smaller databases, how do I handle the relationships? Maybe this means that I shouldn't be breaking them apart.
Can a API backed by a RDMS be refactored into Micro services?
api;microservices
As I understand, with a micro service architecture, each micro service should have its own database.I don't consider that a given.  If you need two different APIs that both require access to the same database, I would think that two microservices would still be a natural fit.I am wondering if it is possible to break up such a schema into sub-schemas, so that it can then refactored from a monolith to a collection of micro services.Do you mean database sub-schemas?  I don't think you need that, unless you believe that it would be advantageous for reasons other than your microservices architecture.If micro services share a database, wouldn't the database become a bottleneck?Unlikely, unless you have an enormous amount of traffic. Modern relational databases are designed to handle this kind of multi-user activity with aplomb.If I can separate my database into a set of smaller databases, how do I handle the relationships?Exactly the reason you shouldn't separate it into multiple databases.There's nothing mystical about microservices.  Microservices are just a response to the complexity of monolithic systems.  As Einstein once said, As simple as possible, but no simpler.