Costumava associar escalabilidade a preocupações de infraestrutura como servidores, alojamento e estratégias de cache. Com o tempo, essa ideia não se sustentou. A maioria dos problemas reais com que me deparei não tinha nada a ver com tráfego ou desempenho no início. Vinham da forma como o sistema estava estruturado desde cedo, especialmente quando essas decisões foram tomadas rapidamente sem pensar em como as coisas iriam evoluir.
Os problemas costumavam aparecer mais tarde, não quando o sistema estava sob carga, mas quando eu precisava de mudar alguma coisa. Uma funcionalidade pequena acabava por tocar em múltiplas partes não relacionadas, ou uma refatorização simples parecia arriscada sem razão aparente. Esse é normalmente o ponto em que o sistema começa a resistir.
Quando as coisas começam a falhar
Há um padrão claro que aparece ao longo do tempo. As funcionalidades começam a demorar mais do que o esperado, as pequenas alterações deixam de ser isoladas e começa-se a hesitar antes de tocar em certas partes do código. Nesse ponto, o problema não é o desempenho. É que o sistema se tornou difícil de compreender e ainda mais difícil de modificar com segurança.
Um erro que continuei a repetir
O erro mais comum que cometi foi misturar responsabilidades sem o notar cedo o suficiente. O código do frontend começava lentamente a incluir lógica que pertencia ao backend, enquanto as respostas do backend eram moldadas em torno da conveniência do frontend em vez de contratos claros. Isto funcionava bem no início, mas ao longo do tempo criava um acoplamento forte entre partes que deviam ter permanecido independentes.
Uma vez que isso acontece, as alterações tornam-se custosas. Não porque sejam tecnicamente difíceis, mas porque são imprevisíveis e fáceis de partir.
As decisões de base de dados são as que mais doem
Os problemas mais dolorosos com que tive de lidar estavam relacionados com decisões de design de base de dados tomadas demasiado cedo. Coisas como relações pouco claras, dados duplicados ou correções rápidas ao esquema que nunca foram revisitadas acabaram por causar problemas a longo prazo. Corrigi-las mais tarde é sempre custoso porque envolve migrações, limpeza de dados e lidar com casos extremos que não deviam existir em primeiro lugar.
A certa altura deixei de pensar na base de dados como apenas armazenamento e comecei a tratá-la como a fundação do sistema. Se essa camada não for sólida, tudo o que é construído em cima torna-se mais difícil de manter.
O que realmente ajudou
As coisas que ajudaram não eram particularmente complexas. Manter fronteiras claras entre camadas, evitar otimização prematura desnecessária e tratar as APIs como contratos estáveis fez uma diferença notável. Para além disso, manter ativamente o sistema simples revelou-se mais valioso do que tentar torná-lo flexível em todas as formas possíveis.
A principal mudança de mentalidade foi perceber que a escalabilidade tem sobretudo a ver com a facilidade de mudar o sistema mais tarde, não com a carga que consegue suportar agora.
O que penso agora
A maioria dos sistemas não falha por ser demasiado pequeno ou não conseguir suportar tráfego. Falha porque se torna difícil de mudar, e uma vez que isso acontece, tudo abranda.
