Callbacks in Ruby on Rails: Full Tutorial & Use Cases

📌 What Are Callbacks?

Callbacks in Rails are methods triggered automatically during the lifecycle of an ActiveRecord object. They hook into events like validation, save, create, update, and destroy.

🔍 Detailed Explanation of Callbacks

In Ruby on Rails, callbacks are special hooks that allow you to run code automatically at specific points in an ActiveRecord object’s lifecycle. Instead of manually calling logic before or after an operation like save or destroy, you can define callback methods that Rails will trigger for you.

For example, if you want to clean up whitespace in a title before saving a blog post, you can use a before_save callback rather than calling the method manually every time. This helps reduce duplication and ensures consistency across your application.

Callbacks are used in models, and they can be helpful in keeping your models clean and concise — but they should be used with care. Excessive or complex callback logic can make it hard to understand what your application is doing.

There are many types of callbacks such as:

• before_validation — runs before validation checks
• before_save — runs before a record is created or updated
• after_create — runs after a record is successfully created
• after_commit — runs only after a successful database transaction
• before_destroy — runs before a record is deleted

These callbacks help automate model behavior, making your code cleaner and more maintainable. But always be careful: for anything complex or business-specific, it’s often better to use a service object instead.

💡 Why Use Callbacks?

• Enforce business logic before or after DB operations
• Send notifications or update external services
• Set or clean attributes automatically
• Reduce code duplication

📘 Important Terms in Rails Callbacks

⏱️ Callback Order & Execution Flow

Yes, the order of callbacks matters. Rails executes them in a strict sequence depending on the action being performed — whether it’s create, update, or destroy. Below is the full flow of callbacks for a record creation:

🧬 Order During Create

1. before_validation
2. after_validation
3. before_save
4. before_create
5. Record is inserted into DB
6. after_create
7. after_save
8. after_commit

🔁 Order During Update

1. before_validation
2. after_validation
3. before_save
4. before_update
5. Record is updated in DB
6. after_update
7. after_save
8. after_commit

❌ Order During Destroy

1. before_destroy
2. Record is deleted
3. after_destroy
4. after_commit

🔁 around callbacks like around_save wrap the save logic — they run before and after save, and must include yield to proceed with the operation.

✅ Why order matters: If you update a field in before_validation, it will be validated. But if you update it in after_validation, it’s already too late to be validated. Always choose the callback stage based on when you need the logic to run.

🧪 When Each Callback Executes (With Examples)

Here’s a breakdown of common callback types and exactly when they run, using a simple User model as reference:

class User < ApplicationRecord
      before_validation :set_username
      after_validation :normalize_email
      before_save :encrypt_password
      before_create :set_default_role
      after_create :send_welcome_email
      before_update :log_changes
      after_update :notify_user
      before_destroy :check_if_admin
      after_destroy :log_deletion
      after_commit :track_analytics
    end

📝 These examples clarify exactly what kind of logic fits best at each stage of the model lifecycle.

🛠️ Custom Callbacks in Rails

While Rails provides built-in callbacks like before_save or after_create, you can also define your own custom callbacks using define_model_callbacks. This is useful when you want to hook into custom events or group reusable lifecycle actions.

📌 Defining a Custom Callback

class Payment < ApplicationRecord
      define_model_callbacks :charge
    
      before_charge :log_start
      after_charge :log_end
    
      def charge_card
        run_callbacks :charge do
          puts "💳 Charging card..."
          # charge logic here
        end
      end
    
      private
    
      def log_start
        puts "🔁 Starting charge..."
      end
    
      def log_end
        puts "✅ Finished charge."
      end
    end

In this example, we define a new callback flow called :charge. When charge_card is called, it runs the before_charge and after_charge callbacks around the card charging logic.

📘 Syntax for Custom Callbacks

• define_model_callbacks :event_name
• before_event_name :method_name
• after_event_name :method_name
• around_event_name :method_name
• Trigger using run_callbacks :event_name do ... end

✅ Use Cases for Custom Callbacks

• Complex domain workflows (e.g., payment, shipment, verification)
• Shared behavior across modules/services
• Better testability and code separation

🧠 Pro Tip: Avoid overusing custom callbacks unless you’re managing complex workflows — they can reduce clarity when abused.

🚫 Skipping Callbacks in Rails (With Examples & Full Explanation)

In some cases — like data migration, seeding, or performance-critical operations — you might want to skip callbacks that normally run when saving, updating, or destroying records. Rails provides multiple ways to do this.

🛑 1.

This method removes a previously declared callback from the model. Use this when you know you never want a specific callback to run anymore — like turning off email notifications in a staging environment.

class User < ApplicationRecord
      before_save :normalize_email
      skip_callback :save, :before, :normalize_email
    end

🔍 Breakdown:

• :save — The callback chain you want to target (save, create, update, etc.)
• :before — Whether it’s a before_, after_, or around_ callback
• :normalize_email — The method name to remove from the chain

⚠️ This removes the callback from the model entirely and affects all records. It is not temporary. Avoid using it inside runtime logic or conditionals.

🔁 2. Skip Callbacks During Updates Using

These methods update the database directly and skip validations and callbacks.

user.update_column(:status, "inactive")       # Skips callbacks and validations
    User.update_all(active: false)               # Mass update, no callbacks

⚠️ Be careful: this bypasses all protections — use only when you're sure the data is safe to update directly.

✅ 3. Skip Conditionally Using a Flag (Safe and Reversible)

You can define a condition inside the callback method using an instance variable or method:

before_save :generate_slug, unless: -> { skip_slug? }
    
    def skip_slug?
      @skip_slug == true
    end
    
    # In controller or service:
    user.instance_variable_set(:@skip_slug, true)

✅ This is safe and temporary — perfect for one-time skips or unit testing.

🚨 4. Using

This skips validations, but not all callbacks. For example:

user.save(validate: false)

This still runs before_save and after_save callbacks, so it’s not a full skip.

🧠 Best Practices

• ✅ Use unless: or if: with a method or flag for one-off skips
• ⚠️ Avoid using skip_callback dynamically — it affects the class globally
• ⚡ Prefer update_column only in scripts, migrations, or trusted internal ops
• 🧪 Clearly document any skipped callback logic to avoid silent bugs

Skipping callbacks should always be intentional. Understand the lifecycle and what you're skipping — especially when dealing with security, encryption, auditing, or notifications.

🐞 When a Callback Doesn’t Run in Rails

Sometimes your callbacks might silently fail or never get triggered. Here are the most common reasons — and how to fix them.

🚫 1. Wrong Lifecycle Callback Used

Using before_create when the record is already persisted will cause the callback to not run.

# This runs only on new records:
    before_create :generate_token

✅ Solution: Use before_save or before_validation if you want to cover both create and update.

🔍 2. Condition Blocks (if:/unless:) Evaluate to False

If a condition returns false, the callback is skipped.

before_save :normalize_name, if: -> { email.present? }

Check the condition at runtime — maybe it doesn't match as expected.

🧪 3. Method is Missing or Misspelled

Rails won’t raise an error if your callback method name is wrong — it just won’t run it.

before_save :normalize_names # wrong method name
    # But the real method is: def normalize_name; end

🛑 4. Using update_column, update_all, or Raw SQL

These skip validations and callbacks.

user.update_column(:status, "active")    # ❌ Skips callbacks
    User.update_all(active: false)           # ❌ Skips all lifecycle hooks

🧼 5. Callback Method Doesn’t Change the Model

If your method doesn’t modify the object or raise an error, you might think it didn’t run — but it did.

before_validation :check_something
    
    def check_something
      puts "I ran!" # But doesn't affect anything visible
    end

🔁 6. Callback Chain is Halted by Another Callback

If an earlier callback uses throw(:abort), the rest won’t run.

before_save :check_permission
    
    def check_permission
      throw(:abort) unless admin?
    end

🔁 7. Callback Skipped by skip_callback or Flag

You (or another dev) may have intentionally skipped the callback and forgot.

skip_callback :save, :before, :normalize_email

🧠 Debugging Tips

• ✅ Add puts or Rails.logger.debug in your callback methods
• ✅ Check for spelling mistakes or method visibility (private methods won’t work in some callback cases)
• ✅ Use a test to verify the callback is triggered (e.g. expect a change or side effect)
• ✅ Check parent class and concerns if the callback is included dynamically

If all else fails, simplify the model and try the callback in isolation. You’ll quickly find whether it’s a logic error or a lifecycle issue.

🎯 Interview Questions & Answers (with Examples)

before_save do
      throw(:abort) if email.blank?
    end

around_save do |record, block|
      log_start
      block.call
      log_end
    end

🔄 Alternatives to Callbacks (With Examples)

Callbacks are helpful, but they can make code harder to understand or debug — especially when logic grows complex. In such cases, it's better to use alternatives like service objects, observers, or concerns for better code organization.

1. ✅ Service Objects (Best Practice)

Encapsulate logic into a dedicated class. Easy to test and reuse.

# app/services/user_creator.rb
    class UserCreator
      def initialize(params)
        @params = params
      end
    
      def call
        user = User.new(@params)
        user.username = user.username.downcase
        user.save!
        SendWelcomeEmailJob.perform_later(user.id)
        user
      end
    end

Usage:

UserCreator.new(params).call

2. 📡 ActiveRecord Observers

Observers allow logic to live outside the model. They listen to lifecycle events like create, update, or destroy.

# app/observers/user_observer.rb
    class UserObserver < ActiveRecord::Observer
      def after_create(user)
        Analytics.track("user_created", user_id: user.id)
      end
    end

Enable it in config:

# config/application.rb
    config.active_record.observers = :user_observer

3. 📦 Concerns (Shared Logic)

Use Rails concerns to share behavior across models. Avoid callback abuse.

# app/models/concerns/slug_generator.rb
    module SlugGenerator
      extend ActiveSupport::Concern
    
      included do
        before_save :generate_slug
      end
    
      def generate_slug
        self.slug = name.parameterize
      end
    end
    
    # In your model:
    class Article < ApplicationRecord
      include SlugGenerator
    end

4. 🧪 Plain Method Calls

Just call the method explicitly in your controller or service. This is the most transparent and beginner-friendly way.

def create
      @user = User.new(user_params)
      @user.prepare_data
      if @user.save
        SendWelcomeEmailJob.perform_later(@user.id)
      end
    end

🧠 When to Use Alternatives

• When logic involves multiple models or side effects
• When you want better testability and traceability
• When callbacks become hard to debug or override

⚠️ Rule of Thumb: Use callbacks for light, model-only logic. For business processes, move to service objects or observers.

🏢 Real World Use Case

In a marketplace app, after a user creates a listing, we:

• Auto-generate a slug with before_validation
• Send notification to admins with after_create
• Schedule indexing job with after_commit

class Listing < ApplicationRecord
  before_validation :generate_slug
  after_create :notify_admin
  after_commit :index_listing, on: :create
end

✅ Best Practices for Callbacks in Rails

Rails callbacks can make your code cleaner and more powerful — but only if used wisely. Follow these best practices to avoid common pitfalls:

🔹 1. Keep Callbacks Lightweight

Callbacks should contain minimal, model-related logic only. Avoid business logic, API calls, or complex flow inside callbacks.

# ✅ Good
    before_save :normalize_name
    
    # ❌ Bad
    before_save :send_invoice_to_customer

🔹 2. Use Service Objects for Business Logic

Extract logic into service objects when it involves more than a few steps or affects other models.

UserOnboardingService.new(user).call

🔹 3. Use

Avoid running callbacks unnecessarily. Add conditionals to limit execution.

before_save :encrypt_password, if: -> { password_changed? }

🔹 4. Prefer Explicit Over Implicit Behavior

If a developer reading your model can’t tell what’s happening just by scanning the code, it’s a red flag.

# ✅ Controller or Service explicitly calls logic
    user.generate_slug

🔹 5. Avoid Chaining Too Many Callbacks

Chained callbacks can lead to complex, unpredictable flows. Keep them clear and few.

🔹 6. Use

For things like emails, jobs, or analytics, always prefer after_commit to avoid triggering them if the transaction fails.

🔹 7. Don’t Depend on Callback Order Too Much

If two callbacks must run in a certain order, combine them or document the order explicitly to avoid confusion.

🔹 8. Test Side Effects of Callbacks

Don’t assume callbacks just “work.” Write unit tests that check whether the expected outcome actually happens.

🔹 9. Avoid Callbacks in Concerns Unless Shared

Keep concerns clean — only include callbacks if shared across multiple models.

🔹 10. Comment Complex Callback Chains

If you must use multiple callbacks, document their purpose and order to help future developers.

🧠 Golden Rule: If it feels like magic, it’s probably not a good callback use case. Keep it simple, testable, and predictable.

🌐 External Resources to Learn More

If you want to go deeper into callbacks in Rails, here are some official and high-quality community resources worth checking out:

• 🔗 Rails Guides: Active Record Callbacks (Official)
  The most comprehensive and up-to-date source on all callback types and usage patterns in Rails.
• 🎓 Learn Ruby Online
  Interactive Ruby learning environment to practice lifecycle and callback concepts from scratch.
• 📦 ActiveRecord Import Gem
  A gem for importing large datasets while skipping callbacks and validations by default.