Coordinating services and managing state
1. Coordinating services and managing state
Welcome back! In the previous video we looked at architecture patterns and communication styles. Now let's explore how services coordinate work together.2. Service Coordination
In real world applications, multiple services must work together to complete a workflow. They need a coordination strategy and two approaches are orchestration and choreography.3. Orchestration
In an orchestration pattern a central service coordinates the workflow. The orchestrator controls the sequence of operations and determines which service runs next. This approach provides clear visibility and control over the workflow and is especially useful when workflows involve retries, conditional logic, or error handling. On AWS orchestration is commonly implemented using AWS Step Functions to coordinate workflows across services such as Lambda, ECS, and DynamoDB.4. Orchestration
Orchestration simplifies debugging and monitoring because the workflow logic exists in one place. However, it introduces a central dependency that all services rely on.5. Choreography
In a choreography pattern, there is no central controller. Instead, services react to events independently and trigger additional actions when needed. Each service listens for relevant events and performs its work without needing to know the full workflow. This approach improves loose coupling and scalability, making it well suited to distributed and evolving systems.6. Choreography
On AWS, choreography is often implemented using Amazon EventBridge, Amazon SNS, and Amazon SQS. Choreography systems are highly scalable but can become harder to understand and debug as workflows grow more complex.7. Event-driven architecture
Event-driven architecture is a pattern where services communicate by producing and consuming events Characteristics of event-driven architectures include: Loose coupling between services, high scalability, parallel processing of events, and extensibility - allowing new services to subscribe without modifying existing ones.8. Event-driven architecture
The trade-off is that developers must design for eventual consistency, idempotency, and failure handling when using event driven patterns.9. Idempotency
Idempotency is when you run the same operation in your application multiple times, it will produce the same result as performing it once. Idempotency is a critical design principle in asynchronous and event-driven architectures. This is important because distributed systems may deliver duplicate events due to retries, network failures, or message reprocessing. Idempotent services ensure that processing the same request or event multiple times produces the same result, preserving system correctness and reliability.10. Dead letter queues
The dead-letter queue (DLQ) pattern is used to manage failures in asynchronous communication systems. DLQs are special queues that isolate problematic messages, often called poison messages, that would otherwise cause repeated failures. When a message cannot be processed successfully after multiple retry attempts, it is moved to a separate queue known as a dead-letter queue instead of blocking the main processing flow.11. Dead letter queues
Dead letter queues work well when you don't depend on strict message ordering. They're unnecessary for non-critical systems where occasional data loss is acceptable. However, avoid them when message ordering is critical.12. Managing state
Understanding state, how it is stored, and how it is shared between services is fundamental to building reliable and scalable cloud-native applications. State refers to any data that must be preserved between interactions. In traditional systems, state was often stored locally within an application server, but in cloud environments this approach limits scalability and resilience.13. Managing state
You will need to consider the trade-offs involved in managing state based on what you are trying to build. Externalizing state improves scalability and resilience, but it can introduce additional latency, increase system complexity, and require thinking around consistency, caching, and data access patterns.14. Stateful
Stateful applications retain session data on the server itself. This means requests from a given user must route to the same instance often via sticky sessions on a load balancer. This limits scaling flexibility and reduces fault tolerance. If that instance fails, the session is gone.15. Stateless
A stateless application treats every request independently no memory of previous interactions is stored on the server. State is stored in external systems. This is the preferred approach for cloud-native applications because any instance can handle any request, making horizontal scaling straightforward. If an instance dies, no data is lost.16. Let's practice!
Let's now practice what we've learned about service coordination and state management!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.