No início da carreira, a gente costuma medir o sucesso de uma stack pela eficiência: "Como eu consigo entregar o máximo de performance gastando o mínimo de recursos?". É um desafio intelectual instigante. No entanto, com o passar dos anos — e alguns incidentes em produção acumulados na bagagem — a métrica muda.
A maturidade profissional não chega quando você domina o framework da moda, mas quando você entende que nem toda decisão técnica é sobre performance ou custo. Algumas decisões são puramente sobre quem segura o rojão quando as coisas dão errado.
Toda ação tem uma reação. E toda falta da ação, uma falta de reação
Antes de seguir: se você está montando um lab em casa ou um projeto de estudo, ignore tudo isso. Mas se tem cliente pagando na outra ponta, as coisas apertam.
O erro comum: confundir preço com risco
Existe uma confusão perigosa na nossa "bolha" de desenvolvimento: a ideia de que o gratuito é inerentemente ruim e o pago é necessariamente bom. Não é bem assim. O problema não está no valor da fatura no final do mês, mas sim em onde esse recurso está posicionado na sua arquitetura.
A verdade é que tudo "funciona até não funcionar". O laboratório aceita qualquer coisa; a produção, não. O erro não é usar um serviço free. O erro é usar um serviço sem garantias no coração da sua aplicação.
O que SLA realmente significa
Vamos para fora dos livros aqui: se você procurar a definição acadêmica de SLA (Service Level Agreement), vai encontrar porcentagens de uptime e cálculos de disponibilidade. Mas, no mundo real - de pessoas carne e osso, com suas próprias motivações - o SLA é outra coisa: é o limite da responsabilidade.
O SLA é a linha que divide o que é um "incidente técnico do fornecedor" do que é "um problema exclusivamente seu":
- Com SLA: Se o serviço cai, existe um contrato, um prazo de resposta e uma obrigação legal.
- Sem SLA: Se o serviço cai, o fornecedor não te deve nada. E "nada", nesse caso, inclui até uma resposta no suporte.
Inclusive, sem SLA, você poder "demitido" por qualquer motivo, em qualquer situação - como explicar isso para seus clientes pagantes? No fim do dia, o SLA é o que separa uma parceria profissional de uma "boa sorte" silenciosa. Um serviço com SLA costuma ter:
- Incident response com janelas definidas
- Prioridade em filas de mitigação durante falhas regionais
- Créditos financeiros ou penalidades contratuais em caso de violação
Sem SLA, não existe fila, não existe prazo e não existe obrigação - e se existe, não existe obgrigação de entregar nada disso. Você não está apenas mais barato na fila — você está fora dela.
Free Tier com SLA
A porta de entrada começa aqui.
Não me entenda mal, eu não sou anti-free. Pelo contrário, muitos serviços excelentes oferecem camadas gratuitas que são pensadas para produção desde o primeiro dia.
Estamos falando de categorias como e-mails transacionais, DNS, serviços de observabilidade básica ou APIs de terceiros. A característica aqui é clara: os limites são explícitos, existe continuidade garantida e, se você estourar o uso, a cobrança é automática. O serviço é gratuito até certo ponto, mas a estrutura de suporte e a seriedade do serviço são as mesmas do plano pago.
Isso é uma estratégia de entrada, não uma aposta no escuro.
Free Tier sem SLA
Aqui, se eu gostasse de emojis, usaria o de sirene e o de alerta várias vezes.
O problema real mora no "gratuito por benevolência". Aquele modelo onde o fornecedor oferece um recurso sem garantias contratuais. Aqui, o cenário muda: contas podem ser encerradas sem aviso, recursos podem ser removidos da noite para o dia e, em caso de instabilidade regional, você é o último da fila de prioridade.
Sem um SLA, você está construindo sua casa em terreno alugado e o dono pode pedir o imóvel a qualquer momento. Se o serviço sumir, todo o downtime e a perda de dados viram um problema que você terá que explicar sozinho para o seu cliente.
Exemplos reais de interrupções em infra crítica em empresas com SLA:
- AWS: em outubro de 2025, a Amazon Web Services sofreu uma grande interrupção em sua região US-EAST-1, afetando plataformas como Reddit, Snapchat, Uber rival Lyft e muitos serviços dependentes. A falha começou num subsistema de rede interno, travando desde DNS até APIs principais por horas. Esse tipo de evento mostra que mesmo provedores gigantes podem ter impacto em core quando um componente central falha.
- Azure: em outubro de 2025 (esse mês foi bravo, ein), a Microsoft enfrentou uma interrupção significativa no Azure Front Door, que impactou serviços críticos como Microsoft 365 (Teams, Outlook, SharePoint) e infraestrutura associada ao ambiente Azure.
O que aprendemos com isso? mesmo um serviço com SLA pode sofrer interrupções; a diferença é que, com SLA, existe processo formal de resposta e compensação possíveis - sem isso, você e seu cliente ficam no vazio e dependem da caridade do provedor, enquanto seu cliente está enviando aquele áudio de 2 minutos para o seu Whatsapp.
Core vs. Borda: A distinção que muda o jogo
Para decidir onde usar o quê, eu utilizo um modelo mental simples: a divisão entre Core e Borda.
- O Core: É o que mantém o sistema vivo. Compute, banco de dados, rede base. Se isso cai, o sistema deixa de existir. No Core, o Free Tier sem SLA é uma aposta perigosa demais para qualquer profissional sério
- A Borda: São os serviços auxiliares. Webhooks de integração, analytics, disparos de jobs secundários ou logs de auditoria não crítica. Se a borda falha, o impacto é contido
Idealmente, até serviços de borda deveriam ter SLA, mesmo quando estão em um free tier. O “gratuito com cobrança automática ao estourar” ainda é um contrato. O “gratuito por benevolência” não é. A diferença não é técnica — é estratégica. Free no core é aposta. Free na borda é estratégia.
O argumento que ninguém gosta de ouvir
Sempre que discutimos isso, alguém levanta a mão e diz: "Mas eu uso o serviço X há cinco anos e nunca tive problema".
Precisamos ser honestos: "nunca tive problema" não é uma métrica de engenharia, é estatística de sorte. E sorte não é uma estratégia de infraestrutura. A senioridade começa justamente quando você decide, de forma consciente, reduzir o risco, em vez de provar que consegue operar no limite do perigo.
Experiência pessoal, por mais longa que seja, não substitui uma garantia contratual quando o desastre bate à porta.
Uma decisão de carreira, não de stack
Quando você trabalha como freelancer ou lidera um projeto, sua reputação está em jogo. Para um projeto pessoal, um final de semana offline é um aprendizado. Para um cliente, é prejuízo e quebra de confiança - e até processos, dependendo do tamanho do buraco.
Escolher pagar por um serviço com SLA - ou optar por um free tier que ofereça garantias mínimas - é uma decisão sobre a sua qualidade de sono e a longevidade da sua carreira. É sobre previsibilidade. É sobre ser o profissional que o cliente confia porque sabe que você não está "brincando" com o negócio dele.
O critério que levo pra a vida
Antes de implementar qualquer serviço em uma aplicacão em produção para um cliente final, faço um pequeno checklist mental:
- Esse serviço possui um SLA claro?
- Se ele cair agora, quem é o responsável por responder?
- Se ele sumir amanhã, qual o tamanho do meu esforço de migração?
- Eu estou economizando dinheiro ou estou apenas assumindo um risco que não me pertence?
Uma engenharia madura não se trata de extrair cada gota de performance da stack ou economizar cada centavo de dólar. Trata-se de saber onde não brincar.