Как мы переехали на event-driven (и не пожалели)

Событийная архитектура в Ruby-приложениях позволяет эффективно разделять бизнес-логику и упрощает масштабирование кода. Используя механизмы pub/sub с помощью инструментов вроде Wisper или RailsEventStore, разработчики могут создавать гибкие и отказоустойчивые системы. Такой подход особенно полезен при переходе к микросервисам и работе с PostgreSQL в контексте DevOps.

Когда количество команд в проекте переваливает за сотню, а бизнес-логика начинает пересекаться — пора задуматься о событийной архитектуре.

🧱 До: монолит команд

Всё завязано напрямую:

Order.create(...)
Analytics.track_order_created(...)
NotifyUser.call(...)

Каждый шаг знает о другом. Добавить новый? Придётся трогать старый код.

📣 После: публикуем события

Вместо вызова всех зависимостей — генерируем событие:

order = Order.create(...)
EventBus.publish('order.created', order: order)

А подписчики сами разберутся.

🎧 Подписчики

class NotifyUserOnOrder
  def call(event)
    NotifyUser.call(order: event[:order])
  end
end

EventBus.subscribe('order.created', NotifyUserOnOrder.new)

🎯 Преимущества

• 🔌 Слабое связывание — можно отключать и добавлять подписчиков
• 🔄 Повторная отправка событий (если что-то пошло не так)
• 🚀 Масштабируемость и переход к микросервисам

🧩 Варианты реализации

• Wisper — простой pub/sub
• RailsEventStore — с сохранением истории
• Kafka / RabbitMQ — если уходите в микросервисы
• Свой EventBus — для начала хватит и обычного класса

🧪 Отладка

Важно:

• Логируйте события
• Оборачивайте подписчиков в rescue
• Добавьте retry или DLQ (dead-letter queue)

📌 Вывод

События — это как внутренние Webhooks. Они делают архитектуру гибче и расширяемее. Просто не забывайте: порядок доставки не гарантирован. Ваши подписчики должны быть идемпотентны.