Shared Nothing Architecture

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.

Takeaways

1. 1

   Each event uses a separate Rails application instance and SQLite database; a typical database is about one megabyte.

2. 2

   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.

3. 3

   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.