Reducing ActiveRecord Callback Chains by 80% Using POROs

"Our callback hell was so bad, even Rails creators would’ve cried."

ActiveRecord callbacks start innocent—a quick before_save here, an after_commit there. But before you know it, your User model has 14 nested callbacks, your test suite takes 12 minutes to boot, and debugging feels like defusing a bomb.

We cut our callback madness by 80%—without losing functionality—by embracing Plain Old Ruby Objects (POROs). Here’s how we did it (and why you should too).

1. The Callback Spiral of Doom

What Went Wrong?

Our Invoice model once looked like this:

class Invoice < ApplicationRecord before_validation :generate_number after_create :send_welcome_email after_save :update_customer_stats after_commit :notify_accounting_team, on: :create after_commit :sync_with_erp, if: -> { status_changed? } # ...and 9 more end 

The Problems:

• Untestable (need to run full ActiveRecord lifecycle)
• Brittle (change one callback, break three others)
• Slow (every Invoice.save triggered 12+ side effects)

2. The PORO Rescue Plan

We replaced callbacks with single-responsibility service objects.

Before (Callback Madness)

# app/models/invoice.rb after_create :send_welcome_email def send_welcome_email InvoiceMailer.created(self).deliver_later end 

After (PORO Clarity)

# app/services/invoice_creator.rb class InvoiceCreator def initialize(params) @invoice = Invoice.new(params) end def call Invoice.transaction do @invoice.save! InvoiceMailer.created(@invoice).deliver_later # Explicit > implicit AccountingSync.new(@invoice).perform end end end # Usage: InvoiceCreator.new(params).call 

Key Benefits:
✅ Explicit flow (no hidden side effects)
✅ Easier testing (mock dependencies individually)
✅ Faster tests (no ActiveRecord callbacks = no DB bloat)

3. Real-World Refactoring

Case 1: Payment Processing

Before (Nested Callbacks):

class Payment < ApplicationRecord after_create :charge_credit_card after_commit :update_invoice_status private def charge_credit_card PaymentGateway.charge(amount) # What if this fails? update!(status: :processed) # Another callback trigger? end def update_invoice_status invoice.mark_as_paid! # Yet more callbacks... end end 

After (PORO Orchestration):

class PaymentProcessor def initialize(payment) @payment = payment end def call Payment.transaction do PaymentGateway.charge(@payment.amount) @payment.update!(status: :processed) InvoiceMarker.new(@payment.invoice).mark_as_paid! end rescue PaymentGateway::Error => e @payment.fail!(e.message) # Controlled error handling end end 

Result:

• 50% fewer bugs in payment flows
• 3x faster tests (no cascading callbacks)

4. When to Keep Callbacks

Not all callbacks are evil. Keep them for:
✅ Simple persistence logic (e.g., before_save :normalize_name)
✅ Non-critical path operations (e.g., after_create :log_creation)

Golden Rule:

If it talks to external services or other models, it belongs in a PORO.

5. The Hidden Bonus: Better Debugging

Before:

# Debugging callback chains [1] pry> invoice.save # ??? Which of the 14 callbacks failed? 

After:

[1] pry> InvoiceCreator.new(params).call # => Error in PaymentGateway (line 12) 

6. Migration Strategy

1. Identify harmful callbacks (look for after_commit, external API calls)
2. Extract to POROs (one class per workflow)
3. Write integration tests (verify the whole flow)
4. Monitor in production (compare error rates)

Pro Tip: Use the after_party gem to migrate existing callback data safely.

"But Our Team Loves Callbacks!"
Start small:

1. Pick one messy model
2. Extract just its worst callback
3. Compare test speeds

Radically simplified your Rails app? Share your story below!