Migrating from Monolith to Microservices for Payment Processor with 3 Million Daily Transactions

This payment startup has grown to over 3 million transactions daily in 3 years. How do you scale a startup company at such a growth rate without sacrificing productivity?

The whole organization is built upon autonomous independent teams.

Over the past few years, it has become evident that it is increasingly hard to arrange the work between the teams when everybody is working on a single monolithic application.

Therefore, it became apparent that some architectural refactoring needs to be done.

So we decided to move towards the microservices architecture. Microservices is a software architecture paradigm that constitutes an application of small and independent services communicating with one another through standardized APIs.

Architecture

Since we want to have our solution as cloud agnostic as possible we have have chosen a solution which does not tie us to any specific cloud as our default stack as mentioned in column 3.

Explanation

Event Sourcing

1. Both our Monolith and our new budding microservices will be tasked to write events to the Event Stream. Any change (mutation) in the overall state of the system will go to the stream.
2. The mutation, once validated and possibly transformed into a resulting event, will be propagated to any other downstream service via the Event Stream.
3. We would want to store our events forever. That would allow you to write quick ETLs that are selective about what events to play back in the stream. And could also be a way to create point in time snapshots for each entity, so that instead of having to play back everything from January 1st, 1970 (when, as we all know, the world started), we could start from yesterday.

MicroServices Communication

Microservices will communicate in two ways :

1. Synchronous
2. Asynchronous Event Driven Communication

Authentication and Authorization

We can have two types of Authentication mechanisms :

1. API Gateway : All microservices call go through an API Gateway. All authentications and authorizations are performed here . In our case Ocelot
2. Authentication at every Service : This way each call from one Service to another is authenticated. This is more secure but is an overkill in our situation. If we still need to go with this approach we will use JWT

AKS Internal Architecture

Kubernetes Ingress

The way to expose our app is by using a Kubernetes Service. There are four types of services, or ServiceTypes.

• ClusterIP
• NodePort
• LoadBalancer
• Kubernetes Ingress.

We will be using Kubernetes Ingress.