Interview: Cloud Design Patterns

1. Circuit Breaker
2. Command and Query Responsibility Segregation (CQRS)
3. Event Sourcing
4. Backend-for-Frontend

Circuit Breaker — Application resiliency patterns

Resiliency is the ability of your system to react to failure and still remain functional.

When a Service 1 understands there are continuous failures/ timeouts when Service 2 is called, instead of retrying, Service 1 trips the calls to Service 2 and returns the fallback response.

Libraries, like Netflix’s Hystrix, that can be used to implement this pattern very easily.

If you’re using API gateways or sidecar proxies like Envoy, then this can be achieved at the proxy level itself.

Note: It’s very important that there’s sufficient logging and alerting implemented when the circuit is open in order to keep track of requests received during this time and that the operations team is aware of this.

When to use this pattern

• When a service is dependent on another remote service, and it’s likely to fail in some scenarios
• When a service has a very high dependency (for example, master data services)

When not to use this pattern

• When you’re dealing with local dependencies — a Circuit Breaker might create overhead

Command and Query Responsibility Segregation (CQRS)

CQRS pattern suggests using different data models for the read and writes operations.

Note: These days some people also prefer to implement read replicas as fast and performant NoSQL databases, like MongoDB and Elasticsearch.

Note: Most PaaS databases these days provide the ability to create read replicas (Google Cloud SQL, Azure SQL DB, Amazon RDS, etc.) of the data stores which help to achieve replications of data much easier.

When to use this pattern

• When you’re looking at scaling an application expecting a huge number of reads and writes

Event Sourcing

Event Sourcing is an interesting design pattern where a sequence of domain events is stored as a journal, and an aggregated view of the journal gives the current state of the application.

Considering a hotel room reservation system in which the users are expected to book or cancel reservations. Here you need to store the bookings and cancellations as a series of events. Before every booking, an aggregated view shows the available rooms by looking at the events journals.

Note: Most cloud-service providers support messaging services like Google Pub/Sub, Azure Service Bus, AWS SQS, etc. These services, in combination with strong consistent data stores, can be used to implement this pattern.

When to use this pattern

• When regular CRUD operations aren’t good enough to meet the demands
• Typically suitable for seat-reservation systems — like bus, train, conferences, movie halls, etc. — or e-commerce systems that consist of events like cart operations, payments, etc.
• When there’s a requirement of strong auditing and events replay to create a current and past state of applications

Backend-for-Frontend (BFF)

Here, you’re expected to build/customize back-end services for the specific front end.

When to use this pattern

• When you want to deliver a product/service for different clients, like desktop and mobile clients
• When you want to optimize the response for a particular type of client
• When you want to reduce chatty communication between mobile clients and various services. These days if you’re using an API gateway, the BFF pattern can be easily implemented in the gateway itself, and you don’t need to maintain separate services.

API Gateway

1. It provided Unified point of entry into the system. It helps to implement BFF

Azure API Management (APIM) consists of three components:

1. the API Gateway,API Management exposes a gateway server that allows controlled access to back-end services based upon configurable rules and policies.
2. Restrict service access — Block calls from specific IP addresses.

When not to use this pattern

• When the application users are expected to use a single user interface