Architecture Patterns and Reliability

How to organize software, handle failures, release changes safely and keep applications running during outages.

1. How should we organize an application? p. 1

Imagine you're building an online shopping application. It needs to manage customers, products, orders and payments. You could build everything into one application, or split these responsibilities into separate services.

Monolith p. 1

One deployable application contains all major features. Advantage: Simple to develop, test and debug initially. Trade-off: Scaling or changing one part may require deploying the whole application.

Modular monolith p. 1

One deployable application with clear internal module boundaries. Advantage: Keeps deployment simple while improving maintainability. Trade-off: Teams must enforce boundaries between modules.

Microservices p. 1

Independent services can be deployed and scaled separately, with each service owning its data. Advantage: Independent releases and scaling. Trade-off: Network, consistency and operational complexity.

Which should you choose? p. 1

PDF page 22. Other architecture patterns p. 2

These patterns solve specific design and organizational problems. They can be combined; they are not mutually exclusive.

Organize around business capabilities p. 2

Split services where responsibilities and ownership are clear. Conway's Law observes that system designs tend to reflect communication structures within the organization, so architecture and team boundaries should be considered together.

3. Reliability: when a dependency fails p. 2

Suppose the recommendation service becomes slow. If each product page waits for it, the whole website may become slow. A resilient design contains that failure.

This is called graceful degradation: optional functionality can fail while the most important user journey remains usable.

PDF page 34. The main reliability patterns p. 3

Circuit breaker states p. 3

PDF page 45. Retries can make failures worse p. 4

Retries are useful for temporary failures, but multiple service layers retrying independently can multiply the work sent to an already struggling dependency.

Use bounded retries, exponential backoff, jitter, deadlines and idempotency. Avoid independently retrying at every layer without accounting for their combined effect.

6. How do we release changes safely? p. 4

A new application version may contain bugs. Release strategies limit how much traffic is exposed before the team has evidence that the change is healthy.

Rolling p. 4

Replace instances in small batches. Trade-off: Old and new versions coexist temporarily, so interfaces and database changes must be compatible.

Blue-green p. 4

Switch traffic from the old environment to a prepared new one. Trade-off: Fast rollback, but two environments cost more.

Canary p. 4

Send a small share of traffic to the new version, then increase it if healthy. Trade-off: Needs strong metrics and automated rollback.

Other techniques: Feature flags let teams deploy code without enabling it immediately. Dark launches run new functionality without exposing results to users. Shadow traffic sends copies of real requests to a new system for comparison, with side effects safely controlled.

PDF page 57. Containers and Kubernetes p. 5

A container packages application code and its dependencies into a consistent runtime unit. Kubernetes helps operate containers across a cluster of machines.

8. Multi-region architecture p. 5

Large applications may run in multiple geographic regions to reduce latency for distant users and improve disaster recovery.

Active-passive: one region normally serves traffic while another is prepared for recovery. Active-active: multiple regions serve traffic at once, potentially improving latency and capacity, but making data conflicts and coordination harder.

PDF page 69. Disaster recovery: plan for the region outage p. 6

RPO p. 6

Recovery Point Objective How much data loss is acceptable? Example: recover within the agreed five-minute loss window.

RTO p. 6

Recovery Time Objective How long can the service remain unavailable? Example: restore service within 30 minutes.

Failover test p. 6

Recovery evidence Can the team really restore and route traffic as planned? Practice recovery before an actual disaster.

Exact recovery times depend on architecture, data replication, automation and tested procedures. The strategy name itself does not guarantee a specific RPO or RTO.

10. Cells and bulkheads p. 6

A cell-based architecture divides users into groups, each served by an independent application stack. The goal is to limit how widely a failure can spread.

If Cell A fails, the intended outcome is to limit the impact to its assigned users rather than bringing down the whole system. Cells add complexity around data placement, routing and spare capacity during failover.

Apply the concepts p. 6

PDF page 7Chapter recap p. 7

• Monoliths are simpler to start with; modular monoliths add boundaries; microservices support independent ownership and scaling at additional complexity.
• Timeouts, retries, circuit breakers, bulkheads and fallbacks help contain failures.
• Rolling, blue-green and canary deployments manage release risk in different ways.
• Containers package applications, while Kubernetes helps deploy and operate them.
• Multi-region systems improve resilience but need careful data and failover design.
• RPO defines tolerable data loss; RTO defines the recovery-time target.
• Cells and bulkheads reduce the blast radius of failures.

Check your understanding p. 7

1. A small team is building an early-stage product. Which architecture is a reasonable starting point?

1. Microservices for every feature

2. A monolith or modular monolith

3. Active-active multi-region by default

2. A dependency repeatedly times out. Which pattern temporarily stops new calls to it?

1. Circuit breaker

2. Canary deployment

3. Database migration

3. What is the main purpose of a canary deployment?

1. Send all traffic to the new version immediately

2. Expose a small share of traffic to a new version and monitor it

3. Replace backups with replicas

4. What does an RPO describe?

1. The maximum acceptable data loss window

2. The maximum acceptable service recovery time

3. The maximum number of application servers

5. Why use a cell-based architecture?

1. To guarantee failures never happen

2. To limit a failure's impact to a subset of users

3. To eliminate the need for monitoring

6. Why can retries increase the severity of an outage?

1. They always reduce request volume

2. Multiple retry layers can multiply load on a struggling dependency

3. They automatically convert async calls to sync calls

Answers and explanations p. 8