A scaling review for a sensitive-data Rails app

Some work is small, careful, and confidential by nature. This was one of those.

The engagement

The client ran an identity- and income-verification product — the kind of system that checks people against payroll and credit data, handles very sensitive personal information, and was mid-way through SOC 2 certification. That last detail set the tone: before I could see a line of code, there was an NDA and a background check.

They didn't want a developer to build features. They had a Rails app on Heroku, talking to an external SQL Server database over a whitelisted connection, and they wanted to know how it would hold up — memory errors they'd seen in staging, performance under load, and readiness to scale. The deliverable was a written consulting report.

Access was deliberately limited: read-only on their repositories, the whole time. I was there to review and advise, not to ship.

What I did

To make the report worth anything, I had to actually run the system, not just read it. So I stood the app up locally — which in this case meant building the SQL Server client library from source with SSL support, wiring up the encrypted-attribute keys the seed data needed, and working through the environment until it ran against test data.

From there:

• A schema review of the Rails app's PostgreSQL database.
• A performance code review against the symptoms they'd flagged — the staging memory errors and the scaling concerns.
• A configuration and infrastructure review of the production picture: the Heroku web and worker dynos, Redis, the single Postgres instance, and the external SQL Server it depended on.

The result was a written report with recommendations at both the architecture level and the line level — short-term wins they could act on quickly, mixed with longer-term practices to keep the system healthy as it grew.