Production environment

The application should be put into production on a Kubernetes cluster. A load balancer should direct the traffic to a fair amount of nodes in the cluster. At least one microservice in the setup must be configured to scale to more than one replica, ensuring it can handle increased load efficiently.

Staging environment

You should have a staging environment that is the same as the production environment throughout the project. This can be a separate Kubernetes instance or a namespace in the production cluster.

Replication of database

To handle potential variations in read and write loads, implement at least one of these patterns:

• Shared Database with CQRS: Keep one database for all but add read replicas to boost read performance if needed.

• Command Query Responsibility Segregation (CQRS): Split read and write operations between different databases.

• Database-per-Service: Give each microservice its own database for flexible scaling and performance tweaks.

Choose the best fit for your application.

Deployment pipeline

One important aspect of the project is to have a well-defined deployment pipeline making sure every team member can provide changes to the project. Early in the project, the team should agree on a deployment pipeline anatomy. It should at least include:

• triggers
• stages being used
• what to do on failed tests
• responsibilities
• secrets shared

We are aiming for Continuous Improvement during the project.

Continuous Delivery principles

The team should work using continuous delivery principles. Integrations should be done frequently (no less than every other day for a single branch). Early in the project, the team should agree on which Continuous Delivery (CD) principles to adopt. Those should at least include:

• branching strategy
• merging (how, when, ...)
• mono repo or multi repo
• team practices (when to work, meetings, tools, ...)

Testing

In an optimal project, we should have 100% coverage with tests. In this project, the team should have tests but the coverage is allowed to be low. However:

• every microservice created should have a test that is fairly easy to fail (frontend service excluded).
• there should be at least one automated integration test that simulates many requests to test the entire system, ensuring that the scaling functionality for the microservice(s) is working correctly.

Optionals

• Use blue/green Deployment for rollouts.
• Use a GitOps flow for the production part of the Kubernetes cluster.
• Smoke testing
• Implement observability
• Istio service mesh with sidecars
• ...