• Decompose by business capability
• Decompose by subdomain
• Self-contained Service
• Service per team

We decomposed our service using decomposition by subdomain, which means that each subdomain corresponds to a different part of the business. We try to avoid splitting the business relation set of functions between other services and making our developers easy to understand and manage. This way, services are loosely coupled. 

E.g., our architecture embraces the following list of microservices:

• Pages MS 
• Domains and Users MS
• Products MS
• Orders MS
• Product Deliveries MS
• Payments MS
• Integrations and mapping MS
• SSR WebPage rendering MS
• Statistics MS

Definitely, in this approach, you need to understand your business very well to decouple architecture properly. 

We thought about a Self-contained Service approach, but they are much harder to maintain in splitting business logic and responsibility. Same functions may be implemented in different services, which we want to avoid as much as possible.

An example of the structure of that service you can see in picture:

• Database per Service
• Shared database
• Saga
• API Composition
• CQRS
• Domain event
• Event sourcing

Our approach:

We chose a database per service approach, but we have one service which has a shared database. It was decomposed from other MS and is not temporal because there were many data dependencies. Removing those dependencies would take too much time. So in the future, we are planning to do it, but we have more significant priorities at the moment.

In BOWWE, each MS has its own database, which is either MySQL, Cassandra, or Redis. We also use Redis as a distributed cache.

Such structures complicate situations when specific tasks demand access to two different databases owned by two other microservices. Sometimes tasks need to change multiple different databases to execute tasks. In BOWWE, we have had such a type of problem, especially in ‘Orders MS’, which requires communication between products, payments, and delivery microservices.

We considered the CQRS approach, but for this time, it was additional effort and cost for us, so we decided to leave it as an option in the future in case of performance issues.

An example of that databases structure you can see in picture above.

Service Component Test - we use the service Component Test by mocking external service calls. This approach is easier and cheaper. It doesn't require a cross-service test environment setup, but we can have some integration problems that our tests won't catch. 

Consumer-driven Contract Test - we are using those kinds of tests to test integration with external services and ensure that their contract has not been changed. So, in that case, we are doing a Consumer-side contract test at the same time. 

We are also using cypress for end-to-end and visual regression tests, which allows us to decrease the number of manual testing before each release and gives us better confidence that the functionality we release is working fine.

• Multiple service instances per host
• Service instance per host
• Service instance per VM
• Service instance per Container
• Serverless deployment
• Service deployment platform

Our approach:

We are using the approach of having multiple services per host. Our services are running on dedicated servers. This is more cost-effective for us in comparison with hiring cloud infrastructure.

We are planning to run each service in a separate container. It will make our services more scalable and easier to configure.

An example of that approach you can see in picture:

• Remote Procedure Invocation
• Messaging
• Domain-specific protocol
• Idempotent Consumer

Our approach:

For communication, we are using RestAPI and Apache Thrift. Apache Thrift is a framework with a cross-language code generator that helps us build faster communication between clients and services regardless of the used development languages. In BOWWE, Apache Thrift is used for communication between services responsible for getting page data. We choose Apache Thrift because of better latency compared to Rest API and programming language independence. Apache Thrift supports most of the languages, and our core services are written in Java and PHP. We also use REST APIs where latency is not so important and for our public API.

An example of that RestAPI communication structure you can see in picture:

• Log aggregation
• Application metrics
• Audit logging
• Distributed tracing
• Exception tracking
• Health check API
• Log deployments and changes

Our approach:

None of the above. 

Each service instance generates its logs and writes to a log file in a standardized format. The log files contain errors, warnings, information, and debug messages. So far, this approach is good enough for us. In the future, we may start to use dedicated tools like, e.g., Splunk, Logstash, or Appdynamics. 

Regarding observability, we can add that BOWWE possesses a dedicated microservice that delivers deep analytics about traffic and customer behavior to the owners of the websites. Tech stack of that microservice: 

Spring Boot uses the NoSql Cassandra database. In the future, we are thinking about introducing Apache Spark.

From our experience, building microservices architecture from the very beginning of the project was an excellent decision. Definitely, in the beginning, we have spent a higher number of working hours on the architecture design of the solution, but later it was much easier to develop each functionality separately and manage a few development teams simultaneously. At this point in the project life, adding such significant parts of code like e-commerce creator and later in the future web app builder would be impossible without this architecture. 

If you would like to ask about more details of that project, please don't hesitate to contact us via kuba@ulansoftware.com email address.