Simplify Ruby Conditionals with Pattern Matching

The Problem: Verbose Conditionals When Parsing Payloads

When you receive a JSON webhook from a third‑party service, the payload can vary wildly. A typical Ruby controller might contain a long if/elsif/else chain that checks the top‑level type field, then drills into nested hashes to extract values. As the number of event types grows, the chain becomes hard to read and error‑prone.

Thesis: Pattern Matching Makes the Intent Clear

Ruby’s pattern matching, available since 2.7, lets you write a case statement that both tests a value and deconstructs it in one readable line. Instead of separating the test from the extraction, you can express “if the payload looks like this, bind these parts to variables” directly.

Worked Example: Refactoring a Webhook Handler

Before: Traditional Conditionals

def handle_webhook(payload)
  if payload['type'] == 'payment.succeeded'
    amount = payload.dig('data', 'object', 'amount')
    currency = payload.dig('data', 'object', 'currency')
    process_payment(amount, currency)
  elsif payload['type'] == 'invoice.payment_failed'
    invoice_id = payload.dig('data', 'object', 'id')
    retry_invoice(invoice_id)
  else
    Rails.logger.warn "Unsupported webhook type: #{payload['type']}"
  end
end

After: Using Pattern Matching

def handle_webhook(payload)
  case payload
  in { 'type' => 'payment.succeeded',
       'data' => { 'object' => { 'amount' => amount,
                                 'currency' => currency } } }
    process_payment(amount, currency)
  in { 'type' => 'invoice.payment_failed',
       'data' => { 'object' => { 'id' => invoice_id } } }
    retry_invoice(invoice_id)
  else
    Rails.logger.warn "Unsupported webhook type: #{payload['type']}"
  end
end

The in clauses do two things: they verify the structure and bind the matched parts to local variables. If the payload does not match any pattern, the else branch runs, just like before.

Trade‑off: Readability vs. Runtime Overhead

For simple flat patterns the C‑implemented matcher is roughly as fast as a comparable case with literal checks. When patterns become deeply nested or involve many guards, each level adds a small amount of work. In most web‑request handlers the difference is negligible, but if you place pattern matching inside a tight loop that processes thousands of items per second, you may want to benchmark.

You can compare the two approaches with Ruby’s built‑in Benchmark module:

require 'benchmark'

payload = { 'type' => 'payment.succeeded',
            'data' => { 'object' => { 'amount' => 1000, 'currency' => 'USD' } } }

Benchmark.bm do |x|
  x.report('pattern') { 100_000.times { case payload; in { 'type' => 'payment.succeeded',
                                                            'data' => { 'object' => { 'amount' => a,
                                                                                      'currency' => c } } }
                                            a; end } }
  x.report('traditional') { 100_000.times { if payload['type'] == 'payment.succeeded'
                                              payload.dig('data', 'object', 'amount')
                                            end } }
end

Run the snippet on your target Ruby version and inspect the user‑time columns. If the pattern version is consistently slower by more than a few percent, consider keeping the traditional form for that hot path.

Adopting Pattern Matching Safely

• Check the interpreter version early: abort "Ruby 2.7+ required" unless RUBY_VERSION >= "2.7".
• Cover new patterns with unit tests that assert both the matched branch and the fallback.
• Start with low‑risk code (e.g., service objects, background jobs) before moving to performance‑critical loops.
• If you need to support older Rubies, guard the syntax with eval or use a backport gem such as ruby-pattern-matching (note: this is a community gem; verify its compatibility).

Actionable Closing

Pick one controller or service method that currently uses a long if/elsif chain. Replace it with a case … in statement using the shape of the data you expect. Run your test suite, then run a quick benchmark as shown above to confirm latency stays within your budget. If the numbers look good, propagate the change to similar modules. Over time you’ll see clearer intent‑revealing code without sacrificing the reliability you expect from Ruby.