The FTGO application and the Database per service pattern
One of the key characteristics of the microservice architecture is that each service’s data is private, e.g. the Database per Service pattern.
As the pattern points out, you aren’t required to have a separate database server for each service. Instead, multiple services can share the same database server with a logical separation of their data.
I’ve recently enhanced my book’s example application (FTGO) to properly demonstrate this pattern. Each service has database credentials that only grant it access its own (logical) database on a shared MySQL server.
Here, for example, is the configuration for the Order Service:
ftgo-order-service:
build: ./ftgo-order-service
environment:
SPRING_DATASOURCE_URL: jdbc:mysql://mysql/ftgo_order_service
SPRING_DATASOURCE_USERNAME: ftgo_order_service_user
SPRING_DATASOURCE_PASSWORD: ftgo_order_service_password
The ftgo_order_service_user/ftgo_order_service_password credentials only grant it access to the ftgo_order_service database:
CREATE USER 'ftgo_order_service_user'@'%' IDENTIFIED BY 'ftgo_order_service_password';
create database ftgo_order_service;
GRANT ALL PRIVILEGES ON ftgo_order_service.* TO 'ftgo_order_service_user'@'%';
The other services (Accounting Service, Consumer Service Kitchen Service, and Restaurant Service) have a similar configuration.
The Order History Service, which implements a CQRS view, has its own DynamoDB tables.
To learn more
- Look at the FTGO application
- Read my Microservices patterns book
- Talk to me about my microservices consulting and training services.
- Learn more about microservices at adopt.microservices.io
Premium content and office hours is now available for paid subscribers at 
