Architecture styles and communication patterns
1. Architecture styles and communication patterns
Welcome to Development with AWS Services, a course designed to help developers build the knowledge needed to design, develop, secure, and deploy modern cloud applications using AWS.2. Your instructor
I'm Ricardo, a Principal Technologist with nearly 15 years experience working with AWS. I've spent the last 8 years working at AWS helping developers understand how to build cloud native applications.3. What are architecture patterns?
An architectural pattern is a repeatable solution to a common problem in software design. Patterns help you know how to fit together AWS services into reliable systems. Architecture determines whether an application scales smoothly or struggles under load. To build modern cloud-native applications, you need to know about several architectural patterns.4. Monoliths
A monolith application runs as a single, tightly coupled unit. One codebase, one deployment. It's simple to develop initially, but scaling becomes painful because you must scale *everything* together, even if only one feature is under heavy load.5. Microservices
Microservices break that monolith into small, independent services, each responsible for a specific business capability. Each service can be deployed, scaled, and updated independently. The tradeoff? Increased operational complexity and the need for robust service communication.6. Serverless
Serverless is an architectural pattern that removes infrastructure management letting you focus purely on code and configuration. You build applications by composing managed services and AWS handles all provisioning, scaling, and maintenance. The tradeoff? You accept constraints like execution time limits, cold starts, and vendor lock-in in exchange for near-zero operational overhead and automatic scaling.7. Event-driven architecture (EDA)
Event-driven architecture (EDA) is an architecture pattern where components communicate by producing and consuming events rather than calling each other directly. An event is a record that something happened: "order placed," "payment received," "item shipped." Producers emit events. Consumers subscribe to the events they care about.8. Tightly and loosely coupled systems
Modern cloud applications rarely consist of a single service. They are made up of multiple components that must communicate and coordinate with each other to complete a unit of work. These interactions rely on synchronous (tightly coupled) and asynchronous (loosely coupled) communication patterns.9. Synchronous communication
In a synchronous communication pattern, one service sends a request and waits for a response before continuing. The calling service is blocked until the response is returned or a timeout occurs. Synchronous communication is straightforward to implement and understand, but it introduces tight coupling between services. If a downstream service is slow or unavailable, the calling service must wait, which increases latency and can cause cascading failures. To improve resilience, developers implement timeouts, retries, and circuit breaker patterns in synchronous architectures.10. Pattern: request/response
The request–response communication pattern forms the backbone of most application interfaces.This pattern provides predictable behavior and immediate feedback to users.11. Asynchronous communication
In an asynchronous communication pattern, the sender does not wait for an immediate response. Instead, it sends a message or event and continues processing. The receiving service processes the message independently. Asynchronous communication helps systems scale and improves fault tolerance because services are loosely coupled. Processing happens independently, so asynchronous systems handle traffic spikes more efficiently and continue operating even if some components are temporarily unavailable. Asynchronous workflows introduce challenges such as duplicate messages, ordering concerns, and eventual consistency, which developers must handle through careful design.12. Pattern: queue-based decoupling
In the queue based decoupling pattern, a producer sends messages to a queue; consumer processes messages independently. This prevents system failures from cascading and allows services to scale independently.13. Pattern: worker queue
In the worker queue pattern, multiple workers pull messages from a queue and process them in parallel. This enables horizontal scaling and improves throughput. The trade-off here is that message order is not guaranteed.14. Pattern: publish/subscribe
In the (pub/sub) pattern, publishers send messages to an SNS topic, and multiple subscribers receive them. This allows you to support real-time broadcasting to many consumers.15. Pattern: fan-out
The fan-out pattern is an asynchronous pattern where one message is delivered to multiple consumers simultaneously. Fan-out patterns are widely used in event-driven architectures where multiple services must react to the same event.16. Message ordering
In asynchronous and event-driven architectures, some workloads require messages to be processed in the correct sequence to maintain consistency. AWS services such as Amazon SQS FIFO queues and Kinesis support ordered processing, but strict ordering can reduce throughput, so architects must balance correctness with scalability.17. Let's practice!
Now let's practice with some exercises!Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.