local_bus 0.2.0 → 0.3.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f435ed1460835bdd4b50311c366c158f4dda0381038368cd325a13c8ceace3b9
-  data.tar.gz: 937b58aa97ed2e9ca2f65eb02b6c401f9e93c4d590aff5966816dd6dd47be8a9
+  metadata.gz: fc19202ff3881f3519fd8cfe760b7b83f42fff39cb2b9658d2550fbd2b0bcca0
+  data.tar.gz: 2d2fc75beaa51eb84f2263dc82aa0049c3c2f51b24c32939f911c0b774ef74f9
 SHA512:
-  metadata.gz: 74828920b50a51ae3fc00583dee61657d88cadd62482172fc34c1e54e935a652306716242c9152d6a5f35e9660f6d52930c6840966dc281f158c391666588cf7
-  data.tar.gz: d7c86027a16144325f3ea4cd3e65f41ea55a56ac6b75e309a75a5397cd7042372002783948f64b6e76d3cdbb0200a1cd0b62be3ec8c632b3639c5c33b0a42a76
+  metadata.gz: 44e7b2c60c2be6b5435cc1a652ee624502b775ee503662f582cb32d884e082cb47ee2b8159a27080e820530988aaa4cc5fc3e47f420629d9a0a0b3be7b0a665d
+  data.tar.gz: 647481ca9e89a0239e26ea622c8551757d991595f52a1ba3aac06a0ac03a7266a8f42253dbd8cec30311361d49a2ed2bdd80e95f62648365d95e817de2a34853

data/README.md

@@ -1,300 +1,390 @@
-<p align="center">
-  <a href="http://blog.codinghorror.com/the-best-code-is-no-code-at-all/">
-    <img alt="Lines of Code" src="https://img.shields.io/badge/loc-328-47d299.svg" />
-  </a>
-  <a href="https://rubygems.org/gems/local_bus">
-    <img alt="GEM Version" src="https://img.shields.io/gem/v/local_bus">
-  </a>
-  <a href="https://rubygems.org/gems/local_bus">
-    <img alt="GEM Downloads" src="https://img.shields.io/gem/dt/local_bus">
-  </a>
-  <a href="https://github.com/hopsoft/local_bus/actions">
-    <img alt="Tests" src="https://github.com/hopsoft/local_bus/actions/workflows/tests.yml/badge.svg" />
-  </a>
-  <a href="https://github.com/testdouble/standard">
-    <img alt="Ruby Style" src="https://img.shields.io/badge/style-standard-168AFE?logo=ruby&logoColor=FE1616" />
-  </a>
-  <a href="https://github.com/sponsors/hopsoft">
-    <img alt="Sponsors" src="https://img.shields.io/github/sponsors/hopsoft?color=eb4aaa&logo=GitHub%20Sponsors" />
-  </a>
-  <a href="https://twitter.com/hopsoft">
-    <img alt="Twitter Follow" src="https://img.shields.io/twitter/url?label=%40hopsoft&style=social&url=https%3A%2F%2Ftwitter.com%2Fhopsoft">
-  </a>
-</p>
+[![Lines of Code](https://img.shields.io/badge/loc-364-47d299.svg)](http://blog.codinghorror.com/the-best-code-is-no-code-at-all/)
+[![GEM Version](https://img.shields.io/gem/v/local_bus)](https://rubygems.org/gems/local_bus)
+[![GEM Downloads](https://img.shields.io/gem/dt/local_bus)](https://rubygems.org/gems/local_bus)
+[![Tests](https://github.com/hopsoft/local_bus/actions/workflows/tests.yml/badge.svg)](https://github.com/hopsoft/local_bus/actions)
+[![Ruby Style](https://img.shields.io/badge/style-standard-168AFE?logo=ruby&logoColor=FE1616)](https://github.com/testdouble/standard)
+[![Sponsors](https://img.shields.io/github/sponsors/hopsoft?color=eb4aaa&logo=GitHub%20Sponsors)](https://github.com/sponsors/hopsoft)
+[![Twitter Follow](https://img.shields.io/twitter/url?label=%40hopsoft&style=social&url=https%3A%2F%2Ftwitter.com%2Fhopsoft)](https://twitter.com/hopsoft)
 
 # LocalBus
 
-LocalBus is a lightweight pub/sub system for Ruby that helps organize and simplify intra-process communication.
+### A lightweight single-process pub/sub system that enables clean, decoupled interactions.
+
+> [!TIP]
+> At under 400 lines of code. The LocalBus source can be reviewed quickly to grok its implementation and internals.
+
+## Why LocalBus?
+
+A message bus (or enterprise service bus) is an architectural pattern that enables different parts of an application to communicate without direct knowledge of each other.
+Think of it as a smart postal service for your application - components can send messages to topics, and other components can listen for those messages, all without knowing about each other directly.
+
+Even within a single process, this pattern offers powerful benefits:
+
+- **Decouple Components**: Break complex systems into maintainable parts that can evolve independently
+- **Single Responsibility**: Each component can focus on its core task without handling cross-cutting concerns
+- **Flexible Architecture**: Easily add new features by subscribing to existing events without modifying original code
+- **Control Flow**: Choose immediate or background processing based on your needs
+- **Testing**: Simplified testing as components can be tested in isolation
+- **Stay Reliable**: Built-in error handling and thread safety
+- **Non-Blocking**: Efficient message processing with async I/O
 
 <!-- Tocer[start]: Auto-generated, don't remove. -->
 
 ## Table of Contents
 
-  - [Why LocalBus?](#why-localbus)
+  - [Key Benefits](#key-benefits)
+    - [Performance and Efficiency](#performance-and-efficiency)
+    - [Ease of Use](#ease-of-use)
+    - [Decoupling and Modularity](#decoupling-and-modularity)
+    - [Reliability and Safety](#reliability-and-safety)
+  - [Use Cases](#use-cases)
+  - [Key Components](#key-components)
+    - [Bus](#bus)
+    - [Station](#station)
+    - [LocalBus](#localbus)
   - [Installation](#installation)
-  - [Quick Start](#quick-start)
-    - [Interfaces](#interfaces)
-    - [Bus (immediate processing)](#bus-immediate-processing)
-    - [Station (background processing)](#station-background-processing)
-  - [Advanced Usage & Considerations](#advanced-usage--considerations)
+    - [Requirements](#requirements)
+  - [Usage](#usage)
+    - [LocalBus](#localbus-1)
+    - [Bus](#bus-1)
+    - [Station](#station-1)
+  - [Advanced Usage](#advanced-usage)
     - [Concurrency Controls](#concurrency-controls)
-      - [Bus Interface (Async)](#bus-interface-async)
-      - [Station Interface (Thread Pool)](#station-interface-thread-pool)
-    - [Error Handling & Recovery](#error-handling--recovery)
+      - [Bus](#bus-2)
+      - [Station](#station-2)
+        - [Message Priority](#message-priority)
+    - [Error Handling](#error-handling)
     - [Memory Considerations](#memory-considerations)
     - [Blocking Operations](#blocking-operations)
     - [Shutdown & Cleanup](#shutdown--cleanup)
     - [Limitations](#limitations)
+    - [Demos & Benchmarks](#demos--benchmarks)
   - [See Also](#see-also)
-  - [Sponsors](#sponsors)
 
 <!-- Tocer[finish]: Auto-generated, don't remove. -->
 
-## Why LocalBus?
+## Key Benefits
 
-A message bus (or enterprise service bus) is an architectural pattern that enables different parts of an application to communicate without direct knowledge of each other. Think of it as a smart postal service for your application - components can send messages to topics, and other components can listen for those messages, all without knowing about each other directly.
+LocalBus offers several advantages that make it an attractive choice for Ruby developers looking to implement a pub/sub system within a single process:
 
-Even within a single process, this pattern offers powerful benefits:
+### Performance and Efficiency
 
-- **Decouple Components**: Break complex systems into maintainable parts that can evolve independently
-- **Single Responsibility**: Each component can focus on its core task without handling cross-cutting concerns
-- **Flexible Architecture**: Easily add new features by subscribing to existing events without modifying original code
-- **Control Flow**: Choose immediate or background processing based on your needs
-- **Testing**: Simplified testing as components can be tested in isolation
-- **Stay Reliable**: Built-in error handling and thread safety
-- **Non-Blocking**: Efficient message processing with async I/O
+- **Non-Blocking I/O:** Leveraging the power of the `Async` library, LocalBus ensures efficient message processing without blocking the main thread, leading to improved performance in I/O-bound applications.
+- **Optimized Resource Usage:** By using semaphores and thread pools, LocalBus efficiently manages system resources, allowing for high concurrency without overwhelming the system.
 
-## Installation
+### Ease of Use
 
-```sh
-bundle add local_bus
-```
+- **Simple Setup:** With straightforward installation and intuitive API, LocalBus allows developers to quickly integrate pub/sub capabilities into their applications.
+- **Minimal Configuration:** Default settings are optimized for most use cases, reducing the need for complex configurations.
 
-## Quick Start
+### Decoupling and Modularity
 
-### Interfaces
+- **Component Isolation:** LocalBus enables clean separation of concerns by allowing components to communicate through messages without direct dependencies or tight coupling.
+- **Scalable Architecture:** Easily extend your application by adding new subscribers to existing topics, facilitating the addition of new features without modifying existing code.
 
-- **Bus**: Single-threaded, immediate message delivery using Socketry Async with non-blocking I/O operations
-- **Station**: Multi-threaded message queuing powered by Concurrent Ruby's thread pool, processing messages through the Bus without blocking the main thread
+### Reliability and Safety
 
-Both interfaces ensure optimal performance:
+- **Built-in Error Handling:** LocalBus includes error boundaries to ensure that failures in one subscriber do not affect others, maintaining system stability.
+- **Thread Safety:** Designed with concurrency in mind, LocalBus provides thread-safe operations to prevent race conditions and ensure data integrity.
 
-- Bus leverages async I/O to prevent blocking on network or disk operations
-- Station offloads work to a managed thread pool, keeping the main thread responsive
-- Both interfaces support an explicit `wait` for subscribers
+## Use Cases
 
-### Bus (immediate processing)
+LocalBus is versatile and can be applied to various scenarios within a Ruby application. Here are some common use cases and examples:
 
-Best for real-time operations like logging, metrics, and state updates.
+<details>
+<summary><b>Decoupled Communication</b></summary>
+<br>
+Facilitate communication between different parts of a component-based architecture without tight coupling.
 
 ```ruby
-bus = LocalBus::Bus.new # ... or LocalBus.instance.bus
-
-bus.subscribe "user.created" do |message|
-  AuditLog.record(message.payload)
-  true
+# Component A subscribes to order creation events
+LocalBus.subscribe "order.created" do |message|
+  InventoryService.update_stock message.payload[:order_id]
 end
 
-# publish returns a promise-like object that resolves to subscribers
-result = bus.publish("user.created", user_id: 123)
-
-result.wait  # blocks until all subscribers complete
-result.value # blocks and waits until all subscribers complete and returns the subscribers
+# Component B publishes an order creation event
+LocalBus.publish "order.created", order_id: 789
 ```
 
-Subscribe with an explicit `callable`.
+</details>
+
+<details>
+<summary><b>Real-Time Notifications</b></summary>
+<br>
+Use LocalBus to send real-time notifications to users when specific events occur, such as user sign-ups or order completions.
 
 ```ruby
-callable = ->(message) { "Received message: #{message.payload}" }
-LocalBus.instance.bus.subscribe "user.created", callable: callable
+# Subscribe to user sign-up events
+LocalBus.subscribe "user.signed_up" do |message|
+  NotificationService.send_welcome_email message.payload[:user_id]
+end
+
+# Publish a user sign-up event
+LocalBus.publish "user.signed_up", user_id: 123
+```
 
-subscribers = LocalBus.instance.bus.publish("user.created", user_id: 123).value
-# => [#<LocalBus::Subscriber:0x0000000126b7cf38 ...>]
+</details>
 
-subscribers.first.value
-# => "Received message: {:user_id=>123}"
+<details>
+<summary><b>Background Processing</b></summary>
+<br>
+Offload non-critical tasks to be processed in the background, such as sending emails or generating reports.
 
-# you can use any object that responds to #call
-class ExampleCallable
-  def call(message)
-    "Received message: #{message.payload}"
-  end
+```ruby
+# Subscribe to report generation requests
+LocalBus.subscribe "report.generate" do |message|
+  ReportService.generate message.payload[:report_id]
 end
 
-LocalBus.instance.bus.subscribe "user.created", callable: ExampleCallable.new
-subscribers = LocalBus.instance.bus.publish("user.created", user_id: 123).value
-# => [#<LocalBus::Subscriber:0x0000000126b7cf38 ...>]
+# Publish a report generation request
+LocalBus.publish "report.generate", report_id: 456
+```
+
+</details>
+
+## Key Components
+
+### Bus
+
+The Bus acts as a direct transport mechanism for messages, akin to placing a passenger directly onto a bus.
+When a message is published to the Bus, it is immediately delivered to all subscribers, ensuring prompt execution of tasks.
+This is achieved through non-blocking I/O operations, which allow the Bus to handle multiple tasks efficiently without blocking the main thread.
+
+> [!NOTE]
+> While the Bus uses asynchronous operations to optimize performance,
+> the actual processing of a message may still experience slight delays due to I/O wait times from prior messages.
+> This means that while the Bus aims for immediate processing, the nature of asynchronous operations can introduce some latency.
+
+### Station
+
+The Station serves as a queuing system for messages, similar to a bus station where passengers wait for their bus.
+
+When a message is published to the Station, it is queued and processed at a later time, allowing for deferred execution.
+This is particularly useful for tasks that can be handled later.
 
-subscribers.first.value
-# => "Received message: {:user_id=>123}"
+The Station employs a thread pool to manage message processing, enabling high concurrency and efficient resource utilization.
+Messages can also be prioritized, ensuring that higher-priority tasks are processed first.
+
+> [!NOTE]
+> While the Station provides a robust mechanism for background processing,
+> it's important to understand that the exact timing of message processing is not controlled by the publisher,
+> and messages will be processed as resources become available.
+
+### LocalBus
+
+The LocalBus class serves as the primary interface to the library, providing a convenient singleton pattern for accessing both Bus and Station functionality.
+It exposes singleton instances of both Bus and Station providing a simplified API for common pub/sub operations.
+
+By default, LocalBus delegates to the Station singleton for all pub/sub operations, making it ideal for background processing scenarios.
+This means that when you use `LocalBus.publish` or `LocalBus.subscribe`, you're actually working with default Station, benefiting from its queuing and thread pool capabilities.
+
+## Installation
+
+```bash
+bundle add local_bus
 ```
 
-### Station (background processing)
+### Requirements
 
-Best for async operations like emails, notifications, and resource-intensive tasks.
+- Ruby `>= 3.0`
 
-```ruby
-station = LocalBus::Station.new # ... or LocalBus.instance.station
+## Usage
+
+### LocalBus
 
-station.subscribe "email.welcome" do |message|
-  WelcomeMailer.deliver(message.payload[:user_id])
-  true
+```ruby
+LocalBus.subscribe "user.created" do |message|
+  # business logic (e.g. API calls, database queries, disk operations, etc.)
+  "It worked!"
 end
 
-# Returns a Promise or Future that resolves to subscribers
-result = station.publish("email.welcome", user_id: 123)
+message = LocalBus.publish("user.created", user_id: 123)
+message.wait        # blocks until all subscribers complete
+message.subscribers # blocks and waits until all subscribers complete and returns the subscribers
+#=> [#<LocalBus::Subscriber:0x0000000120f75c30 ...>]
 
-result.wait  # blocks until all subscribers complete
-result.value # blocks and waits until all subscribers complete and returns the subscribers
+message.subscribers.first.value
+#=> "It worked!"
 ```
 
-Subscribe with an explicit `callable`.
+### Bus
 
 ```ruby
-callable = ->(message) { "Received message: #{message.payload}" }
-LocalBus.instance.station.subscribe "email.welcome", callable: callable
+bus = LocalBus::Bus.new # ... or LocalBus.instance.bus
+
+# register a subscriber
+bus.subscribe "user.created" do |message|
+  # business logic (e.g. API calls, database queries, disk operations, etc.)
+end
 
-subscribers = LocalBus.instance.station.publish("email.welcome", user_id: 123).value
-# => [#<LocalBus::Subscriber:0x0000000126b7cf38 ...>]
+message = bus.publish("user.created", user_id: 123)
+message.wait        # blocks until all subscribers complete
+message.subscribers # waits and returns the subscribers
+#=> [#<LocalBus::Subscriber:0x000000012bbb79a8 ...>]
 
-subscribers.first.value
-# => "Received message: {:user_id=>123}"
+# subscribe with any object that responds to `#call`.
+worker = ->(message) do
+  # business logic (e.g. API calls, database queries, disk operations, etc.)
+  "It worked!"
+end
+bus.subscribe "user.created", callable: worker
+```
+
+### Station
+
+```ruby
+station = LocalBus::Station.new # ... or LocalBus.instance.station
 
-# you can use any object that responds to #call
-class ExampleCallable
-  def call(message)
-    "Received message: #{message.payload}"
-  end
+station.subscribe "user.created" do |message|
+  # business logic (e.g. API calls, database queries, disk operations, etc.)
+  "It worked!"
 end
 
-LocalBus.instance.station.subscribe "email.welcome", callable: ExampleCallable.new
-subscribers = LocalBus.instance.station.publish("email.welcome", user_id: 123).value
-# => [#<LocalBus::Subscriber:0x0000000126b7cf38 ...>]
+message = station.publish("user.created", user_id: 123)
+message.wait        # blocks until all subscribers complete
+message.subscribers # blocks and waits until all subscribers complete and returns the subscribers
+#=> [#<LocalBus::Subscriber:0x00000001253156e8 ...>]
 
-subscribers.first.value
-# => "Received message: {:user_id=>123}"
+message.subscribers.first.value
+#=> "It worked!"
+
+# subscribe with any object that responds to `#call`.
+worker = ->(message) do
+  # business logic (e.g. API calls, database queries, disk operations, etc.)
+  "It worked!"
+end
+station.subscribe "user.created", callable: worker
 ```
 
-## Advanced Usage & Considerations
+## Advanced Usage
 
 ### Concurrency Controls
 
-#### Bus Interface (Async)
+#### Bus
 
-The Bus interface uses Async's Semaphore to limit resource consumption:
+The Bus leverages Async's Semaphore to limit resource consumption.
+The configured `concurrency` limits how many operations can run at once.
 
 ```ruby
-# Configure concurrency limits for the Bus
-bus = LocalBus::Bus.new(max_concurrency: 10)
-
-# The semaphore ensures only N concurrent operations run at once
-bus.subscribe "resource.intensive" do |message|
-  # Only 10 of these will run concurrently
-  perform_intensive_operation(message)
-end
+# Configure concurrency limits for the Bus (default: Etc.nprocessors)
+bus = LocalBus::Bus.new(concurrency: 10)
 ```
 
-When the max concurrency limit is reached, new publish operations will wait until a slot becomes available. This prevents memory bloat but means you should be mindful of timeouts in your subscribers.
+> [!NOTE]
+> When the max concurrency limit is reached, new publish operations will wait until a slot becomes available.
+> This helps to ensure we don't over utilize system resources.
 
-#### Station Interface (Thread Pool)
+#### Station
 
-The Station interface uses Concurrent Ruby's fixed thread pool with a fallback policy:
+The Station uses a thread pool for multi-threaded message processing.
+You can configure the queue size and the number of threads used to process messages.
 
 ```ruby
-# Configure the thread pool size for the Station
+# Configure the Station
 station = LocalBus::Station.new(
-  max_queue: 5_000, # Maximum number of queued items
-  max_threads: 10, # Maximum pool size
-  fallback_policy: :caller_runs # Runs on calling thread
+  limit: 5_000, # max number of pending messages (default: 10_000)
+  threads: 10,  # max number of processing threads (default: Etc.nprocessors)
 )
 ```
 
-The fallback policy determines behavior when the thread pool is saturated:
+##### Message Priority
 
-- `:caller_runs` - Executes the task in the publishing thread (can block)
-- `:abort` - Raises an error
-- `:discard` - Silently drops the task
+The Station supports assigning a priority to each message.
+Messages with a higher priority are processed before lower priority messages.
 
-### Error Handling & Recovery
+```ruby
+LocalBus.publish("default")                # 3rd to process
+LocalBus.publish("important", priority: 5) # 2nd to process
+LocalBus.publish("critical", priority: 10) # 1st to process
+```
 
-Both interfaces implement error boundaries to prevent individual subscriber failures from affecting others:
+### Error Handling
+
+Error boundaries prevent individual subscriber failures from affecting other subscribers.
 
 ```ruby
-bus.subscribe "user.created" do |message|
+LocalBus.subscribe "user.created" do |message|
   raise "Something went wrong!"
-  true # Never reached
+  # never reached (business logic...)
 end
 
-bus.subscribe "user.created" do |message|
-  # This still executes despite the error above
-  notify_admin(message)
-  true
+LocalBus.subscribe "user.created" do |message|
+  # This still executes even though the other subscriber has an error
+  # business logic (e.g. API calls, database queries, disk operations, etc.)
 end
 
 # The publish operation completes with partial success
-result = bus.publish("user.created", user_id: 123)
-result.wait
-errored_subscribers = result.value.select(&:error)
+message = LocalBus.publish("user.created", user_id: 123)
+errored_subscribers = message.subscribers.select(&:errored?)
+#=> [#<LocalBus::Subscriber:0x000000011ebbcaf0 ...>]
+
+errored_subscribers.first.error
+#=> #<LocalBus::Subscriber::Error: Invocation failed! Something went wrong!>
 ```
 
+> [!IMPORTANT]
+> It's up to you to check message subscribers and handle errors appropriately.
+
 ### Memory Considerations
 
-Messages are held in memory until all subscribers complete processing. For the Station interface, this includes time spent in the thread pool queue. Consider this when publishing large payloads or during high load:
+Messages are held in memory until all subscribers have completed.
+Consider this when publishing large payloads or during high load scenarios.
 
 ```ruby
-# Memory-efficient publishing of large datasets
+# memory-efficient publishing of large datasets
 large_dataset.each_slice(100) do |batch|
-  station.publish("data.process", items: batch).wait
+  message = LocalBus.publish("data.process", items: batch)
+  message.wait # wait before processing more messages
 end
 ```
 
 ### Blocking Operations
 
-The Bus interface uses non-blocking I/O but can still be blocked by CPU-intensive operations:
+LocalBus facilitates non-blocking I/O but bottlenecks can still be triggered by CPU-intensive operations.
 
 ```ruby
-# Bad - blocks the event loop
-bus.subscribe "cpu.intensive" do |message|
-  perform_heavy_calculation(message)
-end
-
-# Better - offload to Station for CPU-intensive work
-station.subscribe "cpu.intensive" do |message|
-  perform_heavy_calculation(message)
+LocalBus.subscribe "cpu.intensive" do |message|
+  # CPU bound operation can trigger a bottleneck
 end
 ```
 
 ### Shutdown & Cleanup
 
-LocalBus does its best to handle graceful shutdown when the process exits, and works to ensure published messages are processed.
-However, it's possible that some messages may be lost when the process exits.
+The Station delays process exit in an attempt to flush the queue and avoid dropped messages.
+This delay can be configured via the `:wait` option in the constructor (default: 5).
 
-Factor for potential message loss when designing your system.
-For example, idempotency _(i.e. messages that can be re-published without unintended side effects)_.
+> [!IMPORTANT]
+> This wait time allows for processing pending messages at exit, but is not guaranteed.
+> Factor for potential message loss when designing your system.
+> For example, idempotency _i.e. messages that can be re-published without unintended side effects_.
 
 ### Limitations
 
-- The Bus interface is single-threaded - long-running subscribers can impact latency
-- The Station interface may drop messages if configured with `:discard` fallback policy
-- No persistence - pending messages may be lost on process restart
-- No distributed support - communication limited to single process
-- Large payloads can impact memory usage, especially under high load
-- No built-in retry mechanism for failed subscribers
+- The Bus is single-threaded - long-running or CPU-bound subscribers can impact latency
+- The Station may drop messages at process exit _(messages are not persisted between process restarts)_
+- No distributed support - limited to single process _(intra-process)_
+- Large message payloads may impact memory usage, especially under high load
+- No built-in retry mechanism for failed subscribers _(subscribers expose an error property, but you'll need to check and handle such errors)_
 
 Consider these limitations when designing your system architecture.
 
+### Demos & Benchmarks
+
+The project includes demo scripts that showcase concurrent processing capabilities:
+
+```bash
+bin/demo-bus     # demonstrates Bus performance
+bin/demo-station # demonstrates Station performance
+```
+
+Both demos simulate I/O-bound operations _(1 second latency per subscriber)_ to show how LocalBus handles concurrent processing. For example, on an 10-core system:
+
+- The Bus processes a message with 10 I/O-bound subscribers in ~1 second instead of 10 seconds
+- The Station processes 10 messages with 10 I/O-bound subscribers each in ~1 second instead of 100 seconds
+
+This demonstrates how LocalBus offers high throughput for I/O-bound operations. :raised_hands:
+
 ## See Also
 
 - [Message Bus](https://github.com/discourse/message_bus) - A reliable and robust messaging bus for Ruby and Rack
 - [Wisper](https://github.com/krisleech/wisper) - A micro library providing Ruby objects with Publish-Subscribe capabilities
-
-## Sponsors
-
-<p align="center">
-  <em>Proudly sponsored by</em>
-</p>
-<p align="center">
-  <a href="https://www.clickfunnels.com?utm_source=hopsoft&utm_medium=open-source&utm_campaign=local_bus">
-    <img src="https://images.clickfunnel.com/uploads/digital_asset/file/176632/clickfunnels-dark-logo.svg" width="575" />
-  </a>
-</p>