---
title: "Shared Nothing Architecture"
description: "Shared-nothing architecture is presented as a scaling model for Showcase, a Ruby on Rails ballroom-competition application that began on a Mac Mini and grew to cloud VMs serving events in multiple regions. Because each event has few geographically concentrated users, a roughly one-megabyte SQLite database, about one transaction per second, and typical response times of 100ms or less, the design keeps state separate rather than sharing databases and Redis across events. The implementation runs an event’s services on one Fly.io VM, repeats that unit across machines or regions, and can place multiple event instances on one server with Phusion Passenger, NGINX, volumes, and a shared Action Cable process. It specifies 1GB machines with 2G swap after observing about 220MB idle and 450MB active RAM, and recommends WireGuard; the conclusion is that local state and fewer network calls suit this workload and can improve throughput and reliability."
---

# Shared Nothing Architecture

[Fly.io](https://yomu.fyi/company/fly-io) · Sep 2, 2026

**Type:** Explainer

## Summary

Shared-nothing architecture is presented as a scaling model for Showcase, a Ruby on Rails ballroom-competition application that began on a Mac Mini and grew to cloud VMs serving events in multiple regions. Because each event has few geographically concentrated users, a roughly one-megabyte SQLite database, about one transaction per second, and typical response times of 100ms or less, the design keeps state separate rather than sharing databases and Redis across events. The implementation runs an event’s services on one Fly.io VM, repeats that unit across machines or regions, and can place multiple event instances on one server with Phusion Passenger, NGINX, volumes, and a shared Action Cable process. It specifies 1GB machines with 2G swap after observing about 220MB idle and 450MB active RAM, and recommends WireGuard; the conclusion is that local state and fewer network calls suit this workload and can improve throughput and reliability.

## Context

Showcase was created after a ballroom competition scheduling error exposed the limits of manual spreadsheet-based entry and scheduling. The application initially supported one event on a single Mac Mini, then expanded to events in different cities and regions. Each competition has few users, typically located together, and relatively small workloads.

## Approach / What changed

The design keeps each event’s application state and database isolated, running the required services on one Fly.io VM and repeating that unit across machines or regions. Multiple event instances can share a server through Phusion Passenger, separate SQLite databases on volumes, NGINX configuration, environment variables, and a shared Action Cable process. Resource sizing and WireGuard private networking are also part of the deployment.

## Takeaways

- Each event uses a separate Rails application instance and SQLite database; a typical database is about one megabyte.
- Passenger can host multiple event instances on one server, starting Rails apps when needed and stopping them when idle; the trade-off is accepting cold starts of about two seconds or less on modern hardware.
- Measured memory use is about 220MB per instance when idle and 450MB when active, but the deployment uses 1GB machines and an additional 2G of swap to reduce the risk of out-of-memory crashes.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Fly.io](https://yomu.fyi/topic/fly-io), [Ruby on Rails](https://yomu.fyi/topic/ruby-on-rails), [SQLite](https://yomu.fyi/topic/sqlite)

- Source: [Fly.io](https://fly.io/blog/shared-nothing)
- Source URL: https://fly.io/blog/shared-nothing
- Ingested by Yomu: 2026-09-02T11:56:44.340Z

[Read original post](https://fly.io/blog/shared-nothing)