When I first started interviewing for senior Ruby roles, I made a classic mistake. I focused entirely on the code—the elegant blocks, the metaprogramming, the "Ruby way"—and I completely ignored the infrastructure the code lived on. In a system design interview, the interviewer doesn't care if you know how to use Enumerable#reduce; they care if your application crashes when 10,000 users hit a single endpoint at once.

Take a look at this typical "first draft" of a CSV import feature. It looks clean, right?

class UserImportService
  def initialize(file_path)
    @file_path = file_path
  end

  def call
    CSV.foreach(@file_path, headers: true) do |row|
      User.create!(
        email: row['email'],
        first_name: row['first_name'],
        last_name: row['last_name']
      )
    end
  end
end

# In the Controller
def create
  UserImportService.new(params[:file].path).call
  render json: { message: "Import complete!" }, status: :ok
end

The Request-Response Timeout Trap

If you run this with a 10-row CSV on your laptop, it works perfectly. But in a real production environment, this is a ticking time bomb. Why? Because you're performing heavy I/O and database writes inside a synchronous HTTP request.

Most load balancers (like Nginx or AWS ALB) and app servers (like Puma) have a timeout—usually around 30 to 60 seconds. If that CSV has 50,000 rows, your Ruby process will be stuck in that foreach loop long after the load balancer has given up and returned a 504 Gateway Timeout to the user. Even worse, you're holding onto a database connection for the entire duration, which can lead to connection pool exhaustion, effectively taking down your entire site.

Offloading to Sidekiq and Batching Inserts

To fix this, we need to move from a synchronous design to an asynchronous one. We tell the user "We're working on it" immediately and move the heavy lifting to a background worker. I also want to replace the individual create! calls with a bulk insert to reduce the number of database round-trips.

# In the Controller
def create
  # We upload the file to S3 first, then pass the URL to the worker
  file_url = StorageService.upload(params[:file]) 
  UserImportWorker.perform_async(file_url)
  render json: { message: "Import started. You'll get an email when it's done!" }, status: :accepted
end

# The Worker
class UserImportWorker
  include Sidekiq::Worker

  def perform(file_url)
    rows = []
    CSV.foreach(download_file(file_url), headers: true) do |row|
      rows << { 
        email: row['email'], 
        first_name: row['first_name'], 
        last_name: row['last_name'],
        created_at: Time.current, 
        updated_at: Time.current 
      }

      # Batch insert every 1000 rows to keep memory usage stable
      if rows.size >= 1000
        User.insert_all(rows)
        rows.clear
      end
    end
    User.insert_all(rows) unless rows.empty?
  end
end

By using insert_all (introduced in Rails 6), we send one massive SQL query instead of 50,000 small ones. This is the difference between a task taking 20 minutes and taking 20 seconds.

Thinking in Layers: The System Design Mindset

When you're in a Ruby backend interview, you need to zoom out. Don't just talk about the Ruby class; talk about the layers. If the interviewer asks how to scale this system further, here is the mental checklist I use:

• The Database Layer: Are we hitting a bottleneck? I'd suggest adding a database index to the email column to prevent slow lookups during duplicates checks. If the read volume is huge, I'd suggest adding Read Replicas so the primary DB only handles writes.
• The Caching Layer: Do we have expensive queries running repeatedly? I'd implement Redis to cache frequently accessed data, reducing the load on PostgreSQL.
• The Application Layer: Is one Puma process not enough? We can scale horizontally by adding more app servers behind a Load Balancer.
• The Queue Layer: If UserImportWorker is slowing down other critical tasks (like password reset emails), I'd move it to a dedicated "low-priority" Sidekiq queue so it doesn't clog the system.

Remember, in these interviews, there is rarely one "correct" answer. The goal is to demonstrate that you understand the trade-offs. Choosing Redis adds complexity to your stack, but it buys you speed. Choosing insert_all skips ActiveRecord callbacks (like before_save), but it buys you performance. Mentioning those trade-offs is what signals to the interviewer that you're an experienced engineer.

📋 Practical Task

Design a Rate Limiter for a Ruby API

You are designing a public-facing API for a Ruby on Rails application. To prevent abuse and ensure fair usage, you need to implement a rate limiter that allows users a maximum of 100 requests per minute.

Your Task: Write a technical design proposal (in Markdown or plain text) that explains how you would implement this. Do not write the full implementation code, but provide a "pseudo-code" logic block. Your proposal must address the following:

1. Storage: Where will you store the request counts? Explain why you chose this storage (e.g., Database vs. Redis) in terms of latency and performance.
2. Logic: Describe the algorithm you'll use (e.g., Fixed Window, Sliding Window, or Token Bucket).
3. Middleware: Where in the Ruby/Rails request lifecycle would this logic live to ensure it doesn't slow down the rest of the application?
4. Response: What HTTP status code and header should be returned to the client when they exceed their limit?