Microsserviços ou micro-progresso? Os perigos da pré-escala muito cedo

A grande ilusão do código “à prova de futuro” ah, a música de escalabilidade da sirene. Isso sussurra nada doce em nossos ouvidos: “Construa -o da primeira vez”, “Você agradecerá a si mesmo mais tarde”, “E se você conseguir 10 milhões de usuários amanhã?” E antes que você perceba, você passou três meses arquitetando uma obra -prima deslumbrante dos microsserviços, apenas para perceber que seu aplicativo “escalável” tem exatamente um usuário: você, refrescando a página no modo incógnito. Este era eu. Eu era aquele desenvolvedor. Convencido de que meu projeto paralelo precisava de um cluster Kubernetes, um sistema de notificação distribuído e um serviço de pagamento que pudesse lidar com o tráfego de nível de listras, apesar do meu MVP ainda ser apenas uma lista de tarefas glorificadas. A verdade dura: a escala não importa se ninguém se importa, aqui está a realidade desconfortável: você não pode otimizar os problemas que ainda não tem. Você está se afogando no tráfego do usuário? → Não? Então por que você está construindo um CDN? Você tem 10.000 solicitações de pagamento simultâneas? → Não? Então, por que você está com listras excessivas? Suas notificações estão travando sob carga? → Não? Então, por que você construiu um sistema de sub-sub-sub quando existe a camada gratuita de Novu? Eu tive que enfrentar a música: não estava construindo em escala, estava procrasti-scaling. Evitando o trabalho real (fazendo algo que as pessoas realmente queriam) obcecando com a infraestrutura que pode importar algum dia. O pivô: do excesso de engenharia a “bom o suficiente”, então fiz o impensável: excluí meses de trabalho e o substituí por: supabase (auth + db) → camada livre. Funciona. Feito. NOVU (Notificações) → Nível Grátis. Funciona. Feito. Stripe (Pagamentos) → Integração Básica. Funciona. Feito. De repente, eu estava fazendo um progresso real – não na infraestrutura, mas no produto real. E adivinha? Se (grande se) meu aplicativo superar essas ferramentas, atravessarei essa ponte quando chegar lá. A lição: Construa estúpido primeiro sua primeira versão deve ser embaraçosamente simples. Não porque você é preguiçoso, mas porque: você ainda não sabe o que precisa de escalar. (A maioria das coisas não.) A otimização prematura é a raiz de todo o mal. (Ou pelo menos tempo desperdiçado.) Seu maior risco não é escala, está construindo algo que ninguém quer. Então, da próxima vez que você se pegar projetando um oleoduto Kafka para o seu blog de gatos, pergunte: “Isso está resolvendo um problema real ou apenas meu medo de hipotéticos?” Porque no final, um aplicativo de trabalho com limites supera o “escalável” inacabado toda vez. Agora vá construir algo estúpido. Você sempre pode torná -lo inteligente mais tarde. 🚀

Fonte