Pub/Sub examples

Let’s take a look at a few examples of how we can use pub/sub messaging to address said problems and improve the architecture.

·       Distributed catching

Caches are very crucial tool for improving system performance by having the newest message available to the subscribers stored locally/nearby and updating this copy only changes occur.

With pub/sub, one can seed caches asynchronously. Here processes create data and events, the messaging system transfer the events to caches. As such, instead of expecting a close-by client to form a related request, the info is already within the cache. When new information supersedes data within the cache, a replacement event replaces it. This design is way more efficient in updating state than counting on polling semantics. Using an occasion stream to populate caches prevents the case where your clients are polling for information that isn’t up so far .

Ex. Seats.io is a seating reservation system. (Explore more on this ex)

·       Distributed Logging

With the pub/sub pattern, One can send logs to many subscribed destinations simultaneously. One can have the option of creating explicit logging channels or having message recipients log events in more than one destination.

Pub/sub is well suited for this and hence can add extra flexibility to one of the most crucial monitoring resources in a number of ways without writing new code or building expensive inessential systems.

·       Multiple data resource

Loose coupling within message senders and receivers builds pub/sub systems naturally flexible. One can add new processes anytime, and may remove or replace them as required . Message senders and receivers are repeatedly located anywhere that a connection to the message broker is workable . Additionally, any system are often a sender, a receiver, or both. 

Ex. Experity uses Ably’s pub/sub to collect data from multiple sources and process it with Kafka. (Explore more on this ex like what is experity,kafka) 

·       Burstability and scale

A well-designed pub/sub system can send ordered, messages out to large numbers of subscribers instantly and concurrently as they come and go, connecting and reconnecting unpredictably, and keeping their state in sync.  In terms of design, this is best handled by deploying the task to a selected broker component that is designed to handle busy, unsystematic network behavior (and which ideally also handles data integrity).  Offloading the responsibility of massive to cause bursts messages to a broker gives pub/sub systems a sharp advantage in terms of scale.

Ex. Wooclap is an education tool that allows students to participate in the classroom via a web-based app.