Cloud Design Patterns

In this article, I will discuss the Saga design pattern. First, we’ll address some technical challenges of creating ACID transactions. Then, we’ll explore the Saga design pattern and how to implement it.

Database Per Service Pattern

First, let’s talk about microservice architecture and the database per service pattern. Basically, each microservice in an application has its own dedicated database. This allows each microservice to manage its data independently, making it easier to develop, deploy, and scale each service without affecting the others. For instance, in an online store, the user service, order service, and inventory service each have their own databases. This isolation improves flexibility, as each service can choose the best database type for its needs and makes the system more resilient to failures.

The circuit breaker pattern stops a service from trying again to call another service when the previous attempts have failed multiple times. It’s similar to electrical circuit breakers that automatically cut off the current when there’s abnormal activity.

In a distributed environment, calls to remote resources may fail due to reasons such as application exceptions, timeouts, authentication issues, or overloaded systems. Usually, resilient cloud applications automatically fix these issues over time, and the calling application manages these errors using a retry pattern.

The cloud is vast. Azure docs have around a hundred thousand pages, and AWS is just as big. Other cloud providers are out there too. Each gives you lots of apps, different rules, and dozens of integrations, so creating cloud-native ones has its challenges.

They’re not identical, but big providers offer similar solutions. For example, Google Cloud Storage is like AWS S3 and Azure’s durable function is similar to AWS step functions. Details and rules can differ, but the main idea of the tech is similar, along with the challenges.