Sam Newman, in his book Monolith to microservices: Evolutionary Patterns to Transform your Monolith walking through patterns designed to separating functionality from the monolith into microservices, described the pattern which even though might be hard to use and implement but could be very helpful if you are trying to migrate very risky piece of code to new service. This pattern is called the Parallel Run pattern, and today’s post will be about it.

A few days ago, I wrote a post about the Strangler Fig pattern designed to securely exclude some functionalities from one system to another. I mentioned that when you have a use case where you are changing calls within one system, you must alter all calls and redirect them to your new code.

While reading Building Microservices: Designing Fine-Grained Systems a few weeks ago and Monolith to Microservices: Evolutionary Patterns To Transform Your Monolith by Sam Newman I came across an interesting pattern called Strangler fig that is designed to help exclude some system functionalities, e.g. to the new module or new app. A few simple steps can save time and stress, so I think it is worth exploring.

During one of my recruitment interviews, I was asked how database transactions interact and what influence we have on this. Although I have read about transaction isolation levels in relational databases in the past, I hadn’t had the opportunity to think about this problem in production, so I didn’t initially associate this with what my interviewer was getting at. It seems to me to be a good topic to start, so let’s move on.