Architecture styles and communication patterns

Developing applications on AWS

Ricardo Sueiras

Principal Technologist

Your instructor

What are architecture patterns?

 

 

 

• Repeatable solution to a common problem.
• Patterns help you know how to fit together AWS services.
• Architecture determines how well your app works under load
• Several architectural patterns you need to know.

Monoliths

 

 

 

 

• A single, tightly coupled unit.
• One codebase, one deployment.
• Simple to develop initially.
• Painful to scale: you scale everything together.

Microservices

 

 

• Small, independent services: each owns one business capability.
• Deploy, scale, and update each service independently.
• Tradeoff: more operational complexity and service-to-service communication to manage.

Serverless

• No infrastructure to manage, just code and configuration.
• Build by composing managed AWS services.
• AWS handles provisioning, scaling, and maintenance.
• Tradeoff: execution time limits, cold starts, vendor lock in.
• Near zero operational overhead and automatic scaling.

 

Event-driven architecture (EDA)

• Components communicate by producing and consuming events, not direct calls.
• An event records something that happened (order placed, payment received, item shipped).
• Producers emit events.
• Consumers subscribe to the events they care about.

 

Tightly and loosely coupled systems

• Modern cloud apps are made up of multiple services.
• Services must communicate and coordinate to complete work.
• Synchronous communication is tightly coupled.
• Asynchronous communication is loosely coupled.

Synchronous communication

 

• One service sends a request and waits for a response.
• Caller is blocked until response or timeout.
• Straightforward to implement and understand.
• Tight coupling: downstream slowness or failure can cascade.
• Mitigate with timeouts, retries, and circuit breakers.

Pattern: request/response

• Backbone of most application interfaces.
• Predictable behavior.
• Immediate feedback to users.

Asynchronous communication

 

• Sender does not wait for a response.
• Sends a message or event, then continues processing.
• Receiver processes the message independently.
• Loosely coupled: better scalability and fault tolerance.
• Handles traffic spikes and partial outages gracefully.
• Challenges: duplicate messages, ordering, eventual consistency.

Pattern: queue-based decoupling

• Producer sends messages to a queue.
• Consumer pulls and processes messages independently.
• Prevents failures from cascading.
• Producer and consumer scale independently.

 

Pattern: worker queue

• Multiple workers pull messages from one queue.
• Messages processed in parallel.
• Enables horizontal scaling and higher throughput.
• Message order not guaranteed

Pattern: publish/subscribe

• Publishers send messages to an SNS topic.
• Multiple subscribers receive the same message.
• Real time broadcasting to many consumers.

 

Pattern: fan-out

• One message delivered to multiple consumers simultaneously.
• Widely used in event driven architectures.
• Useful when multiple services must react to the same event.

Message ordering

• Some workloads must process messages in the correct sequence.
• Amazon SQS FIFO and Kinesis support ordered processing.
• Strict ordering reduces throughput.
• Balance correctness with scalability.

Let's practice!

Developing applications on AWS