AWS ‐ Integration Services ‐ EventBridge | Simple Queue Service (SQS) | Message Queue (MQ) | Simple Notification Service (SNS) | AWS Step Function | Simple Workflow (SWF) Service

Event Driven Architecture Pattern

• This architecture comprises multiple decoupled micro services

• Events refer to a change in state or update

• Events trigger communication between services

• Events can carry the state or act as messengers as notifications

• Event Producers

• Event Routers

• Event Consumers

Event producer apps and consumer apps are decoupled, this enables the apps to independently deployed, update, scale.

• Independent scale and fail - no single point of failure
• As it is support decoupled architecture, apps/services can be built in varieties of tech stack in contrast with monolith arch

---

Fault-tolerant design patterns

• Understand the resiliency, scaling aspects to accommodate the demand
• Objective is to build resiliency into workloads
• How do we Build resiliency in our applications
  • Evaluate scaling resources available to accommodate customer demand
  • Goal is to build resiliency in the application itself to handle the workloads, failures

The system should be designed and built to identify the failures and self heal

• Managing Failures

  • Transaction Failure - happens when a component is not available due to heavy load
  • Partial Failure - happens when a batch processing being performed (increases load on resources, hence resource unavailable to serve)
  • Intermittent Failure - happens when network failure

• How do we deal with failures?

  • Retry until success
  • Improves reliability
  • Reduces operational cost

• Backoff: A better approach by enabling clients wait before retries

  • As retrying is not always effective, when a system is already failing due to overload, then the retries will increase the system load
  • Exponential backoff is most common approach to make clients wait for larger intervals exponentially before the retry
  • Maximum delays and no.of retries are normally configured in this approach

• Jitter - when Backoff is not enough

  • In backoff approach, when multiple retries from all backoff systems simultaneously, there is a chance that requests will burst into the system, this will overburden the system, Jitter system modifies the timings of retries by adding some randomness (delaying requests) to the timing of backoff
  • This can be used to reduce the impact of huge burst into the system

• Dealing with Failed Messages (message queue)

  • Failures of Destinations
  • Dead-letter queues