Artery

Main messaging system between Rails [micro]services implementing message bus pattern on NATS (for now).

How to use my plugin.

Add this line to your application's Gemfile:

gem 'artery'

And then execute:

$ bundle

Or install it yourself as:

$ gem install artery

Then install migrations and run (if using ActiveRecord):

$ rake artery:install:migrations
$ rake db:migrate

Artery supports two modes for publishing messages to NATS:

Messages are published directly from the after_commit callback. No additional processes required -- convenient for development and testing. However, under high concurrency after_commit callbacks can execute out of order across transactions, which may lead to incorrect _previous_index values. Recommended for development only.

A separate Publisher process polls artery_messages and publishes them to NATS in strict id order, guaranteeing a correct _previous_index chain. Messages are persisted inside the model transaction (before_commit) without any locks, so there is no contention overhead. Recommended for production.

Artery.configure do |config|
  config.inline_publish = false
end

Running the publisher:

$ bundle exec artery-publisher

The publisher uses a concurrent-ruby thread pool. Pool size is controlled by RAILS_MAX_THREADS (default 5). Each model gets its own thread that polls for unpublished messages.

In admin interface you can list your artery endpoints and check their statuses. You can mount admin ui to your routes via:

mount Artery::Engine => '/artery'

And then you can access it by url http(s)://{ your_app_url }/artery/.

Artery uses ActiveSupport::Notifications for instrumentation and ActiveSupport::TaggedLogging for request-scoped log tagging.

Artery.configure do |config|
  config.service_name = :my_service

  # When true, messages are published inline from after_commit (no publisher needed).
  # Set to false in production when running the publisher process.
  # Default: true
  config.inline_publish = false

  # Log every message (publish/request/subscribe/response).
  # When false, only lifecycle events (errors, sync, connect/disconnect) are logged.
  # Default: true
  config.log_messages = true

  # Maximum bytes of message body included in logs.
  # nil = no limit (full dumps). Default: nil
  config.message_body_max_size = 1024
end

All logs emitted during message processing are automatically tagged with the request ID (reply_to or a generated hex ID). This includes nested operations (enrich, sub-requests) and any Rails logs (e.g., ActiveRecord queries) that go through the shared logger:

[Artery] [Worker] [abc123] [INBOX.xyz789] [RECV] <svc.model.update> {"uuid":"..."}
[Artery] [Worker] [abc123] [INBOX.xyz789]   Source Load (0.5ms)  SELECT ...
[Artery] [Worker] [abc123] [INBOX.xyz789] [DONE] <svc.model.update> (12.3ms)

On Rails 7.0+ with config.active_support.isolation_level = :fiber, this tagging is fiber-safe.

All events follow the event_name.artery convention. You can subscribe to them for metrics, tracing, or custom logging:

ActiveSupport::Notifications.subscribe('request.artery') do |event|
  StatsD.measure('artery.request', event.duration, tags: { route: event.payload[:route] })
end

Available events (each uses a stage:, state:, or action: payload key to distinguish sub-stages):

Contribution directions go here.

The gem is available as open source under the terms of the MIT License.