Turned horizontal scaling back off and bought a bigger machine instead

During one SXSW week, traffic overwhelmed the Blueprint application. I enabled horizontal autoscaling to add capacity. That relieved the first problem, but users then began losing their authenticated sessions as requests reached different dynos.

I turned autoscaling off and moved to a single larger dyno. It restored the operating shape the application had been using while giving it more capacity for the festival. I chose that change over rewriting session handling while the product was live at peak demand.

The first incident looked like a capacity problem: the provisioned application could not handle the traffic arriving during the festival. Adding instances was an available response, and I enabled it without adequately checking authenticated behavior across those instances.

With one dyno, requests returned to the same application process. With several, a subsequent request could reach a different process. My recollection is that authentication worked on the dyno that established it and failed when the request reached another. To a user, the product appeared to forget that they were signed in.

I did not retain the configuration, logs, or a root-cause analysis. I can describe the sequence and the failure class I encountered, but I cannot now identify the exact session implementation responsible. A schematic of process-local authentication helps explain the issue; it should not be mistaken for a recovered deployment trace.

I disabled autoscaling and increased the size of the single dyno. That gave the application more capacity without asking its authentication behavior to work across several processes. It was an infrastructure change I could make in the available incident window.

The choice depended on timing. People were using the guide during the week it was built to serve. Reworking session handling would have changed a critical application path while I was already responding to a second incident.

Horizontal scaling remained a possible direction. It needed authentication to behave consistently regardless of which instance received a request. I chose to defer that work and restore service using a configuration closer to the one the application had already operated under.

A larger single instance had a capacity ceiling and gave me no application-instance redundancy. It also increased the infrastructure I was paying for on a free product. I did not retain the plan sizes or bills, so a precise cost comparison would be speculative.

The change removed the condition exposing the authentication problem. It did not establish that the application was ready to run across instances. If I enabled horizontal scaling again, I would need to revisit that assumption rather than expect additional capacity alone to make the experience reliable.

That distinction matters in describing the result. The larger dyno addressed the immediate incident. It was not a completed redesign of the application's state handling or a general argument against horizontal scaling.

I was responsible for both the original provisioning and the response that introduced the second failure. The missing check was whether a signed-in user could continue through the application when requests reached different instances. Load handling and session continuity needed to be verified together.

Returning to one larger dyno was a reasonable recovery within that week, but the urgency did not make the underlying assumption disappear. I accepted a ceiling and a single instance because those were more manageable at that moment than changing authentication during the festival.

The lesson I carry from this incident is specific: a scaling change also changes where a request runs. Before relying on it, I need to exercise the parts of the application that assume continuity between requests. This account concerns the retired deployment; it makes no claim about how the Blueprint is hosted or authenticated today.