Sumário
Problemas de dimensionamento são problemas que surgem quando um sistema ou aplicativo é incapaz de lidar com quantidades exponencialmente maiores de dados ou tráfego de usuários. Recentemente escrevemos sobre como o freemium quase causou o colapso de nosso negócio devido a esses problemas de dimensionamento. Esta é uma história verdadeira sobre por que dimensionar um aplicativo nunca é tão fácil quanto parece.
Construir software é meio parecido com um conselheiro de acampamento entusiasmado e animado. No início, as crianças são deixadas por seus pais, uma ou duas de cada vez. Cada criança tem alguns pedidos especiais que precisam ser atendidos. Uma tem muita bagagem para ser armazenada. Outra é vegetariana. Outra apenas quer fazer tiro com arco e mais nada.
Tudo bem.
Depois, ônibus cheios de crianças começam a ser deixados — todas acampando gratuitamente, mas todas com bagagem, restrições alimentares, problemas de planejamento. Nada divertido.
Ao final do dia… o pobre conselheiro está destruído.
Software e conselheiros de acampamento têm tanto em comum.
O rastro de boas intenções
- Escreva seu aplicativo em Rails e use Postgres — Tudo é ótimo!
- Adicione um webhook simples para Stripe em Rails como um controlador no aplicativo principal — Estamos indo bem!
- Comece a calcular em segundo plano — use Sidekiq — Ainda ótimo!
- Até que um cliente se inscreva e envie mais de 20.000 eventos em um período de 24 horas.
- Agora, esse webhook simples está deixando o painel principal lento
- Retire o webhook para seu próprio microsserviço pequeno — ele vinha funcionando há meses sem intervenção…
- Importar dados do Stripe por meses funciona ótimo até que um cliente se inscreva com 8.000 eventos em um único dia.
- Agora temos que importar por segmento (2–3 dias de movimento perdidos)
- Nesse mesmo tempo, mais contas se inscrevem, precisamos de mais workers… sem problemas, ative-os!
- Mas espera, workers de alta memória no Heroku literalmente custam um braço, uma perna, um rim e o filho primogênito.
- Somos um negócio bootstrapped, não podemos gastar com isso. Hora de mudar para AWS. Isso é totalmente razoável.
- Eeeek, agora puxar dados para testes locais se torna quase impossível, o que retarda o desenvolvimento. Suspiro.
- Problemas dos workers resolvidos.
- Oh, mas PG tem um problema de limite de conexão mal digno de menção…
- Tudo bem, ative pgbouncer em cada máquina
- Fantástico! Isso funciona, até que não — finalmente mude pgbouncer para sua própria máquina — problemas de conexão resolvidos
- Oh, mas nesse meio tempo, as consultas no servidor de banco de dados estão destruindo a CPU
- Nesse caso, retire uma tabela de alto tráfego para seu próprio banco de dados separado
- Bem, que legal, existem problemas de limite de conexão com o novo banco de dados (repita as lições aprendidas anteriormente)
- Oh, alguém se inscreveu com 4.000 planos — todos os nossos workers por plano estão falhando.
- Nesse meio tempo, o material de marketing no aplicativo principal funciona ótimo inicialmente
- Até que o marketing realmente funciona e milhares de pessoas vão olhar para ele
- O que mata o tempo de resposta do painel principal para clientes pagantes
- O que significa que temos que dividir rapidamente o site de marketing e o aplicativo em peças separadas
- E assim continua…
Não poderíamos ter sabido sobre nada disso no início. Claro, poderíamos ter assumido otimizado para isso, mas então também nunca teríamos lançado o produto em primeiro lugar porque estaríamos passando toda a eternidade otimizando para uma escala que não tínhamos.
Construir e, mais importante, lançar software é sobre a constante troca entre movimento para frente e estabilidade presente.
Silicon Valley está cheia de túmulos de startups que nunca realmente lançaram nada porque estavam determinadas a corrigir problemas que não tinham. Lançar é melhor do que morrer antes de nunca sair da pista. E sim, estou ciente de que é uma metáfora desajeitada. Mas pelo menos eu lancei. 🙂
