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.

Improve this question

1 Answer 1

Reset to default
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."

Improve this answer
0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.