Cloud Design Patterns

An expansive 3D rendering of a futuristic and sophisticated business workflow, depicted in a 100:42 ratio. The scene is filled with numerous high-tech computers, servers, and data centers, all bustling with activity. Each piece of technology is represented by advanced, futuristic machines and holographic interfaces, interconnected by a complex web of glowing data streams and electrical connections. The network operates in a decentralized fashion, emphasizing a collaborative decision-making process without a central hub. Overhead, dynamic beams of light and energy swirl in orchestrated patterns, adding to the sense of an awe-inspiring, orchestrated complexity that characterizes advanced technological systems.

Decentralized workflow coordination using the Choreography pattern

In a microservices architecture, services are divided into smaller ones to work together to process business transactions. This gives us the advantage of being able to develop services quicker and scale them independently. However, designing a distributed workflow is challenging and communication between the services is complex. One approach we could take is to implement a centralized orchestrator that acknowledges all incoming requests and delegates them to the relevant services. The orchestrator manages the entire workflow of the transaction. ...

3D rendering of the Saga design pattern in a vast, futuristic digital universe. The image shows a network of microservices visualized as advanced, intricate nodes, resembling miniaturized, glowing cities with complex pathways. These nodes are connected by robust, multi-layered streams of light in vivid colors and intricate patterns, representing the flow of transactions in a saga. Surrounding the nodes are floating holographic interfaces displaying complex algorithms, code snippets, and real-time transaction data. Above this network, a colossal hologram of a digital globe is central, with beams of light emanating from it, signifying global data consistency management. The scene is set against a cosmic background filled with stars, emphasizing the grand scale and high-tech nature of the Saga design pattern.

Managing Distributed Transactions with the Saga Pattern

In a microservices architecture, we may adopt a database-per-microservice approach to let each domain service us a data store that best serves the type of data that microservices uses. With a database-per-microservice approach, we can scale out our data stores independently, and should our data store fail, that failure will be isolated from other services. However, this approach gets complicated when we need to perform operations in a transactional manner. Transactions must be ACID (atomic, consistent, isolated and durable). Now within a single service, this isn’t too challenging. Across multiple microservices, this becomes difficult to manage. Distributed transactions require all services in a transaction to commit or roll back before the transaction can proceed. Not all data stores support this model. ...

The image is a 3D rendering of an asynchronous messaging subsystem, designed to be visually striking and epic. In the center, a colossal, intensely glowing structure represents the 'Input Messaging Channel'. Attached to this are numerous dynamic extensions, each signifying an 'Output Messaging Channel' leading to futuristic nodes or terminals, symbolizing 'Subscribers'. These nodes are uniquely designed, illuminated, and receiving energy-packed data packets. At the heart of the structure is a spectacular, central hub, resembling a powerful energy core, which orchestrates the flow of messages from the input to the output channels. The background is a vibrant, digital cosmos filled with neon lights, digital patterns, and conveying a sense of vast, technological space. The overall scene emphasizes the scale and intricacy of a high-tech communication network, rendered in a 100:42 aspect ratio.

The Publisher-Subscriber pattern (pub/sub messaging)

In distributed architectures, different parts of our system will need to provide information to other parts as events happens. One way we could solve this is to provision dedicated queues for each consumer and send messages asynchronously to decouple them from message senders. However, this wouldn’t scale if we had to do this for large amounts of consumers, and what if some consumers where only interested in parts of the information that producers send. ...

The image shows a complex 3D rendering of a Sequential Convoy pattern, which is designed to represent a data processing system. Multiple conveyor belts are intricately laid out in parallel and perpendicular formations, each carrying a series of cubes and rectangular blocks in various colors such as blue, green, orange, and pink. These blocks symbolize data packets or messages. The conveyor belts are interlinked but operate independently, showcasing the non-blocking processing of different sequences of data. Each belt runs without interference from the others, indicating the system's ability to handle multiple data streams simultaneously. The overall scene conveys a bustling, efficient data processing facility, with each color-coded or labeled block moving in a defined, orderly sequence, illustrating the concept of processing related messages in order without delaying other processes.

The Sequential Convoy Pattern

In most cases, we will our applications to process a sequence of messages in the order that they arrive. This is especially the case if and when we need to scale out our message processors to handle any increased load in messages. This isn’t always an easy task, because as our application scales out, instances can often pull messages from the queue independently, similar to how this happens when implementing the Competing Consumers pattern. ...

The Asynchronous Request-Reply pattern

Client-side applications often rely on APIs to provide data and functionality, which are either in your control, or provided by a 3rd party. We usually communicate with these APIs using HTTP(S) protocols and REST. Usually, these APIs are designed to respond quickly to requests. However, there can be a variety of things that affect the latency response from these APIs. These include network infrastructure, how many clients are attempting to call the API, the difference in location between the caller and API itself etc. ...