Using a database per service has the following drawbacks: Helps ensure that the services are loosely coupled.Ĭhanges to one service’s database does not impact any other services.Įach service can use the type of database that is best suited to its needs.įor example, a service that does text searches could use ElasticSearch.Ī service that manipulates a social graph could use Neo4j. Using a database per service has the following benefits: The FTGO application is an example of an application that uses this approach.Įach service has database credentials that only grant it access its own (logical) database on a shared MySQL server.įor more information, see this blog post. Without some kind of barrier to enforce encapsulation, developers will always be tempted to bypass a service’s API and access it’s data directly. You could, for example, assign a different database user id to each service and use a database access control mechanism such as grants. It is a good idea to create barriers that enforce this modularity. ![]() Some high throughput services might need their own database server. Using a schema per service is appealing since it makes ownership clearer. Private-tables-per-service and schema-per-service have the lowest overhead.
0 Comments
Leave a Reply. |