Event-Driven Rails in Practice
How we built a lightweight event bus inside a Rails monolith - schemas, idempotency, error isolation, and the one-line call that decouples everything.
Dev
Technical deep-dives and engineering notes from the Kazisafi team
A State Machine in 277 Lines
We needed state transitions with guards, timestamps, callbacks, and instrumentation. AASM was too much. So we wrote our own.
Building a Task Board on the Event Bus
Events decouple side effects. But what if the side effect is work that needs doing? Here's how we turned domain events into an auto-managing task board.
One Event, Start to Finish
Tracing a single leave approval from emit_async through schema extraction, Sidekiq dispatch, subscriber routing, and email delivery. The whole chain, no gaps.
What We Actually Learned
After building an event system across every domain, here's what worked, what surprised us, and the one thing we'd do differently.
The Notifier Pattern - Events Meet Email
How we decoupled notifications from operations with a subscribe_to DSL that routes events to the right mailer, the right recipients, automatically.
Subscribers and the Art of Not Caring
How our event bus dispatches to subscribers with pattern matching, circuit breakers, and exactly-once delivery via Redis.
Schemas, Emitters, and the Shape of an Event
How we define events with a 15-line DSL, auto-register them, and serialize payloads safely. The building blocks of our event system.
Why We Built an Event System (And Why You Probably Shouldn't)
A payroll approval triggers six side effects. We needed them out of the operation. Here's the problem that led us to event-driven architecture.
Working With Us
We're not hiring. But here's the kind of people we want building Kazisafi with us when the time comes.
The Kazisafi Tech Stack
A look at the technologies powering our payroll platform - Rails 8, Hotwire, PostgreSQL, and the architectural decisions behind them.