Application architecture patterns on AWS

Deploying Applications on AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Meet your instructor

Course instructor Dunieski Otano, an AWS Solutions Architect, with around ten years of cloud experience

Why the right architecture matters

Light-theme decision diagram where one architecture choice node branches into three factors, coupling, state, and communication, above a small balance-scale icon for trade-offs

Architecture is a set of trade-offs, not one right answer
- Three questions shape every choice:
  - How tightly are components coupled?
  - Where does the state live?
  - Is communication synchronous or asynchronous?
- Match the pattern to the workload, not to fashion

The Friday night cascade

A slow payment API freezes the whole checkout
Every service waited synchronously on it
The fix is architecture, not a faster API

Side-by-side comparison of tightly coupled services that stall versus services decoupled by a message queue

Why architecture choices decide deployment

Diagram comparing a fragile tightly coupled architecture where one failing service cascades across all services versus a resilient design where a queue buffer isolates the failure so other services keep serving

The pattern you pick shapes how the app scales and fails
- A tightly coupled design breaks under load
The right pattern makes deployment predictable
- Same code, very different production behavior

The core architecture patterns

Monolithic: one deployable unit, simple to start
Microservices: independent services, deployed separately
Event-driven: components react to events, not direct calls
- Fanout is an event-driven sub-pattern: one event reaches many consumers

Three application architecture patterns side by side: monolithic as a single stacked block, microservices as independent deployable services, and event-driven with an event bus, with fanout shown as a labeled sub-pattern inside the event-driven panel publishing one event to many consumers

Stateful vs stateless

Stateless: no client data kept between requests
- Any instance can handle any request
Stateful: instance remembers prior interactions
Statelessness is what lets you scale horizontally
- Push shared state to DynamoDB or ElastiCache

Stateless function instance that any request can reach on the left versus a stateful instance tied to one client session on the right

Tight vs loose coupling

Tight coupling with caller blocked waiting for a slow callee versus loose coupling with an SQS queue buffering messages so the producer keeps working

Tight coupling: caller waits for the callee to respond
One slow service stalls the whole chain
Loose coupling: an Amazon SQS queue sits between services
The producer keeps working even if the consumer is down

Synchronous vs asynchronous

Synchronous: caller blocks and waits for the result
Use when the caller needs the answer right now
Asynchronous: caller hands off work and returns
Use for slow, bursty, or non-urgent work

Synchronous call with caller blocked until response arrives on the left versus asynchronous handoff returning immediately with background processing on the right

Resilience patterns for third-party calls

Retry with exponential backoff: wait longer between attempts
Circuit breaker: stop calling a failing service for a while
Dead-letter queue: park messages that keep failing
Combine them; blanket retries make outages worse

Three resilience patterns: exponential backoff retry curve, circuit breaker halting calls to a failing service, and dead-letter queue capturing messages that exhaust retries

Let's practice!

Deploying Applications on AWS