Dive deep into the intricate world of communication patterns in system architecture. Explore the strengths and trade-offs of request-driven, message-driven, and event-driven models, and how they shape the interaction, scalability, and resilience of modern applications. Unravel the complexities and operational dynamics that can make or break your system’s architecture.
AWS Simple Queue Service (SQS) is a cornerstone in cloud computing, providing robust solutions for messaging and queuing challenges. This post takes a deep dive into the realms where SQS excels, from order processing systems to distributed transaction processing. However, understanding when to pivot towards alternatives like SNS, Kinesis, or Kafka is just as crucial. Uncover the scenarios where SQS is the optimal choice and the circumstances that call for a different strategy.
Understanding the diverse landscape of AWS Messaging Services is essential for architecting robust, scalable, and efficient cloud solutions. AWS offers a suite of messaging services, each designed with unique features and collaboration patterns to cater to specific architectural needs. From SQS’s reliable message queuing and SNS’s dynamic pub/sub messaging to Kinesis’s real-time data streaming and MSK’s high-throughput message handling, the choice of service can profoundly impact your system’s performance, reliability, and scalability. Whether it’s decoupling components with SQS, broadcasting notifications with SNS, processing vast data streams with Kinesis, or handling high-volume events with MSK, understanding these services’ capabilities and use cases is crucial for making informed and strategic architectural decisions.
In this article, I will share my thoughts on using centralised versus decentralised orchestration when building event-driven serverless systems. I have over 15 years of experience in designing and developing distributed event-driven systems. I have spent years migrating from monolithic systems to microservices and now to serverless-powered systems. Event-driven architecture can help build highly loosely coupled, fault-tolerant, scalable,… Read More »
Event-driven architecture is an approach to software design that relies on events to trigger actions. There are five primary patterns of event-driven architecture, including event-notification, event-carried state transfer, CQRS (Command Query Responsibility Segregation), event-sourcing, and event-streaming.
In the article I will describe what they are and the difference between Event-Streaming and Event-Sourcing
The answer is yes. You can combine the two. Let’s look at two possible solutions. FYI, I am basing the solution on a question I received on one of my videos https://youtu.be/U-U3bpljZd0. The question was: Possible Solution Key architecture design decisions for my approach Before we go through the two approaches, let me share my architectural design decisions.… Read More »
An example of the additional complexities which event-driven architecture brings. In this example, I use a combination of Apache Kafka (AWS MKS), Oracle, and Amazon Data Migration Service (AWA DMS) to change an existing synchronous request-driven microservice to a asynchronous event-driven solution.
Have you watched the video How to handle message retries & failures in event driven-systems? Handling retires with Kafka? , but you need more information. Hopefully this post helps. Let’s say you have a consumer, a retry consumer, subscribing to a retry topic. When the retry consumer consumes the retry topic and retrieves message/s, the consumer must check… Read More »