2

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.

4

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."

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.