How would you architect a large Rails app for scale and speed?

Long Answer

Designing a large Rails app architecture that enables fast iteration while keeping domains decoupled is about drawing crisp seams and choosing defaults that favor Server-Side Rendering (SSR) and low-overhead real-time behavior. Rails already gives conventions that speed delivery; the goal is to preserve that speed as the product grows.

1) System shape: modular monolith with Rails Engines

Organize the codebase by business domains using Rails Engines: catalog/, checkout/, billing/, accounts/, and admin/. Each engine owns its routes, controllers, models, migrations, factories, and locale files. Shared concerns (authorization, observability, design system) live in a platform/ engine. Engines expose explicit public APIs (facades, commands, events) so teams integrate via contracts, not reach-through calls. This preserves decoupling while retaining single-deploy simplicity.

2) Application layer: Service Objects and Commands

Move orchestration out of controllers and models into Service Objects (or Command objects) with a uniform interface, for example call returning a Result object. Services coordinate repositories, domain rules, and side effects (emails, webhooks, jobs). Keep Active Record models lean and focused on persistence and simple invariants. Use transactions at the service boundary and emit domain events after commit to avoid ghost effects.

3) Persistence discipline and boundaries

Adopt repository-like patterns per engine to hide query specifics and prevent cross-engine joins. Reference data across engines via identifiers and read models, not foreign keys that couple schemas. For read-heavy features, materialize projections and cache aggressively with versioned cache keys. Keep migrations scoped to the owning engine and run smoke checks for broken dependencies in CI.

4) UI composition with ViewComponent

Build a component library with ViewComponent as the UI contract. Components are small, state-explicit, and fully testable. Compose pages from these primitives and share them across engines. Co-locate templates, previews, and component tests to make UI changes safe. Tie the component library to a design token system so theming is predictable and diffable.

5) SSR first, Hotwire for interactivity

Default to Server-Side Rendering for first paint and correctness. Layer interactive behavior with Hotwire: Turbo Frames for partial page updates, Turbo Streams for real-time broadcasting, and Stimulus controllers for minimal behavior. This delivers live updates without a heavy client framework and keeps the JavaScript surface small. For genuinely rich widgets (charts, editors), lazy-load them and mount as islands to avoid global complexity.

6) Background jobs and real-time delivery

Use Active Job with a robust backend to process side effects and create backpressure protection. Broadcast Turbo Streams from jobs or model callbacks that run after commit. Make all jobs idempotent and enforce unique locks for de-duplication. Provide per-engine job queues and concurrency settings to contain noisy neighbors during promotions or spikes.

7) API and external contracts

When other systems need data, publish narrow, versioned endpoints from the owning engine. Prefer webhooks and events for integrations; keep synchronous APIs small and cacheable. Validate payloads with schema contracts and add contract tests in CI so producers do not accidentally break consumers. Expose feature flags and A/B contexts at the edge to decouple deploy from release.

8) Security, authorization, and policies

Centralize authentication in the platform engine. Implement authorization with policy objects or Pundit and place checks in controllers and ViewComponent helpers. Avoid sprinkling conditionals throughout models. For multi-tenant cases, scope queries by tenant at the repository boundary and enforce row-level constraints defensively.

9) Testing strategy and CI

Adopt a pyramid: unit tests for services and components, request tests for engine endpoints, and a small number of end-to-end flows across engines. Component previews double as visual specs. Use factories per engine and a test application harness that boots only the current engine when possible. Run parallelized tests, seed data builders, and performance smoke tests for high-traffic actions.

10) Observability and performance budgets

Instrument logs with request and correlation IDs. Track RED metrics (requests, errors, duration) per engine and set budgets for LCP and server timings on critical pages. Add bullet-catchers for N+1 queries, a query log dashboard, and cache hit rates. Guard Hotwire broadcasts with metrics so noisy channels do not degrade the rest of the app.

11) Evolution and optional extraction

Stay a modular monolith until data proves otherwise. When an engine needs independent scaling or release cadence, extract it as a service with a stable API and keep data ownership single-writer. Use change data capture or an outbox pattern to publish events and build read models elsewhere. Most teams never need to split everything; selective extraction keeps velocity high.

This approach yields a Rails architecture that is modular, testable, and fast. Engines fence domains, Service Objects orchestrate logic, ViewComponent and Hotwire provide SSR plus real-time interactions, and the platform stays ready for selective service extraction when the graphs demand it.

‍

Table

‍

Common Mistakes

• Treating engines as folders while allowing cross-engine constants, joins, and callbacks.
  
• Fat controllers and fat models that mix orchestration, validation, and I/O.
  
• Sprinkling JavaScript everywhere instead of SSR by default with Hotwire islands for interactivity.
  
• Broadcasting Turbo Streams before transactions commit, causing phantom updates or duplicates.
  
• Relying on global caches and shared queues that let one domain starve others.
  
• No component library; copy-pasted partials drift and slow UI changes.
  
• Unversioned APIs and implicit contracts that break partners during refactors.
  
• Ignoring observability; N+1 queries and cache misses hide until peak traffic.
  
  

Sample Answers

Junior:
“I would split the app into Rails Engines for domains like Catalog and Checkout. I would keep controllers thin and use Service Objects to handle business logic. I would use ViewComponent for reusable UI and default to Server-Side Rendering. For interactivity I would add Hotwire Turbo Streams for updates.”

Mid:
“My Rails architecture uses engines with repository-style data access and Command objects for orchestration. I compose pages with ViewComponent and hydrate behavior with Stimulus where needed. Real-time updates come from Turbo Streams after commit. Each engine owns its routes, migrations, and queues, and I measure performance with RED metrics and N+1 guards.”

Senior:
“I organize domains as engines with strict boundaries, public facades, and versioned contracts. Services run transactions and emit domain events that jobs consume. UI uses a design-tokened ViewComponent library; SSR is default, Hotwire adds low-JS interactivity. I isolate workloads with per-engine queues, track budgets for latency and cache hits, and only extract services when scaling or cadence proves it.”

‍

Evaluation Criteria

A strong response proposes large Rails app architecture as a modular monolith with Rails Engines, thin controllers, and orchestration in Service Objects. It should highlight ViewComponent for reusable, testable SSR UI and Hotwire for real-time updates with minimal JavaScript. Look for repository-like data access to avoid cross-engine coupling, transactional boundaries with after-commit broadcasts, engine-scoped queues, and versioned external contracts. Observability, performance budgets, and CI coverage must be explicit. Red flags include fat models/controllers, implicit cross-engine calls, unguarded broadcasts, unversioned APIs, and no component library.

‍

Preparation Tips

• Create two engines (Catalog, Checkout) with isolated routes, migrations, and factories.
  
• Implement a Command PlaceOrder.call that wraps a transaction, publishes an event, and enqueues jobs.
  
• Build a small ViewComponent library with previews and tokens; replace ERB partials with components.
  
• Add Hotwire: Turbo Frames for the cart and Turbo Streams to broadcast order status after commit.
  
• Introduce repository classes and a projection for “order summary,” then cache with versioned keys.
  
• Configure engine-specific queues, unique jobs, and dead-letter handling; prove idempotency.
  
• Add N+1 guards, server timings, and RED dashboards; set a latency budget for checkout.
  
• Write contract tests for a versioned /orders endpoint and a webhook that confirms payments.
  
  

Real-world Context

A marketplace split its monolith into engines and replaced partials with ViewComponent. UI defects dropped because previews documented behavior. Checkout integrated Hotwire Streams to push payment status; support tickets fell as users saw live updates. Introducing repository patterns prevented cross-engine joins that had caused slow queries. With engine-scoped queues, promotions no longer starved background work in billing. Later, only the checkout engine was extracted as a service behind a stable contract; deploys decoupled without slowing other teams. The Rails architecture stayed fast to iterate while scaling through measured boundaries.

‍

Key Takeaways

• Use Rails Engines to draw real domain boundaries with owned routes, data, and queues.
  
• Keep orchestration in Service Objects; keep controllers and models thin and focused.
  
• Prefer SSR with ViewComponent and add Hotwire for targeted real-time interactivity.
  
• Hide data behind repositories and projections; avoid cross-engine joins.
  
• Measure with budgets and guardrails; extract services only when evidence demands it.
  
  

Practice Exercise

Scenario:
You must deliver a commerce Rails architecture that supports Catalog browsing, a live Cart, and Checkout with payment confirmations. Teams need to move fast, pages must render via Server-Side Rendering, and customers should see real-time status without a heavy single-page framework.

Tasks:

1. Create a modular plan with three engines: catalog, cart, and checkout. Define public facades for each engine and list the data each engine owns.
   
2. Design a PlaceOrder Command that validates input, wraps a transaction, persists the order, emits an order_placed event, and enqueues a confirmation job. Specify the Result object it returns.
   
3. Build a ViewComponent for the cart summary with previews and tests. Use Turbo Frames for partial updates when items change.
   
4. Implement Turbo Streams that broadcast order_status_updated after commit. Show how idempotent jobs ensure duplicate messages do not corrupt state.
   
5. Introduce repository classes for Orders and a projection table for “order summary,” cached with a versioned key strategy.
   
6. Configure engine-scoped queues with concurrency limits and dead-letter handling.
   
7. Add N+1 protections, server timing headers, and a dashboard for RED metrics per engine.
   
8. Version the /orders API and write a contract test that proves backward compatibility for a previous client.
   
   

Deliverable:
A concise architecture note and skeleton code outline demonstrating a decoupled, fast-iterating large Rails app architecture with SSR and real-time features built on engines, Service Objects, ViewComponent, and Hotwire.