Messaging

Many organizations have multiple applications that are being built independently as a microservices-based platform. By its nature, a microservice platform is a distributed system running on multiple processes or services, across multiple servers or hosts. Building a successful platform on top of microservices requires integrating these disparate services and systems to produce a unified set of functionality. It is naïve to think that we can only choose one communication style to solve all problems; if integration needs were always the same, there would be only one style and we would all be happy with it. In reality, a single service can can communicate using many different styles, each one targeting a different scenario and goals. This challenge is what brings me to the topic of this blog post: when and why do we use different communication standards? ...

At first glance, Amazon’s First-In-First-Out (FIFO) message queues provide an excellent feature set for business-critical scenarios. With FIFO, the order in which messages are sent and received is strictly preserved. With exactly-once processing, message duplicates are not introduced into the queue, and consumers control when a message is made available for redelivery. Reading past the marketing hype, how well do FIFO queues work in the real world? This article takes a deep dive into SQS FIFO queues to test the claims of message ordering and exactly-once processing, paying particular care to the conditions under which these claims hold. I show how exactly-once processing can be achieved, and how that message ordering is preserved through failure conditions. I conclude with an examination of the relationship between in-order and exactly-once processing and atomic broadcast and consensus. ...

Workiva’s original product — supporting the mundane task of filing documents with the SEC — was so innovative that within its first 5 years it was being used by more than 65 percent of the Fortune 500 and generating more than $100 million in annual revenue. During that explosion in growth, the software development team focused solely on supporting and expanding the existing software stack. However, after several years of growth and expansion maintaining and extending that single code base became unsustainable. ...

Amazon’s Simple Queue Service (SQS) provides durable messaging guarantees and is an excellent backbone for messaging services. However, SQS does not support “fan-out” of messages so that multiple consuming services can each receive a copy of a message. This means that true publish-subscribe messaging requires some additional work. This post describes some architectural choices that provide durable publish-subscribe messaging using SQS by tracking messaging subscribers using a database, and matching published messages to interested subscribers. ...

Amazon Simple Queue Service (SQS) is a message queue service that allows applications to reliably queue messages from one system component to be consumed by another component. Adding a queue between application components allows them to run independently, effectively decoupling applications by providing a buffer between producers of data and their consumers. Up and Running This section provides a guide to getting up and running with SQS using a fictional music store as an example. This music store has the ability to notify clients of any upcoming events via SQS. ...

When integrating two independent services you have two options: making a remote procedure call (RPC), or sending a message. Which should you choose? What is a Remote Procedure Call? An organization often needs to share data and processes between multiple independent processes in a responsive way. For example, updating a user’s name in a shipping system may trigger updates in a billing system. The shipping system could update the billing system’s data directly by modifying a shared database, but this approach requires the shipping system to know far too much about the internal processes of the billing system. Instead, the business system can encapsulate the update operation behind an interface in the form of a remote procedure call, or RPC. ...

A big portion of any software engineering revolves around integrating multiple, disparate applications into a cohesive and functional whole. These apps may be built in house or third-party, or they may run on your network or distributed geographically, or they may be microservices designed to integrate. In any of these cases, you have several different options for integration, each with pros and cons. The integration patterns listed here are ordered by least to most sophisticated, but also by least to most complex. ...

Point-to-point communication between servers usually works just fine when one or two instances are communicating. One or two instances communicating However, if you increase the number of applications, the total number of connections increases. Three instances communicating In fact, the total number of connections increases as a square of the number of application instances. So, if you are running 100 instances, you will be maintaining O(100^2) connections. The scaling becomes quite painful. ...