O que separa um protótipo em Make de um sistema em produção
O cenário funciona. Montaste-o numa tarde, testaste com cinco registos e passaram os cinco. A sensação é de estar terminado, e é exatamente aí que começa o problema: um protótipo prova que o processo é possível; um sistema em produção prova que continua possível na terça-feira às três da manhã, com um dado estranho e a API do outro lado em baixo. Entre essas duas coisas há trabalho, e não é trabalho de arrastar módulos.
Quando uma automação em Make não escala, quase nunca é a lógica de negócio que falha. Falham quatro coisas que o protótipo não tinha porque não precisava: um tecto de execução que só aparece com volume, um comportamento perante erros que tens de decidir à mão, a ausência total de versionamento e uma fatura que cresce justamente quando fazes as coisas bem.
| Dimensão | Protótipo que funciona | Sistema em produção |
|---|---|---|
| Volume | Cinco registos de teste | O pico de fim de mês, sem avisar |
| Erros | Não houve nenhum | Assume-se que haverá e decide-se o que acontece ao dado |
| Dono | Quem o montou, se se lembrar | Alguém de prevenção, com alerta e procedimento |
| Alterações | Edita-se a quente | Versiona-se, testa-se à parte e promove-se |
| Custo | Cabe folgadamente no plano | Projetado a doze meses com os passos endurecidos |
Nenhuma destas cinco linhas é um defeito do Make. O Make é uma excelente ferramenta para descobrir se um processo se pode automatizar, e essa fase conta. O erro não é começar aí: é ficar aí e chamar-lhe produção.
O tecto de tempo: 40 minutos e o que acontece quando lhe tocas
O Make corta qualquer execução que ultrapasse o tempo máximo. Nos planos pagos esse tecto são 40 minutos; no gratuito, 10. Quando lhe tocas não recebes um aviso simpático: a corrida pára com um erro do género «MAXIMUM EXECUTION TIMEOUT [40 minutes] had elapsed», e o que estava a meio fica a meio.
Um protótipo nunca lhe toca. Processa cinco linhas e acaba em doze segundos. O padrão que rebenta com tudo é sempre o mesmo e sempre por surpresa: um iterador sobre uma lista que cresce. Sincronizas 200 encomendas e corre bem; seis meses depois são 4.000 e o cenário morre a meio caminho, depois de ter queimado as operações das primeiras 2.700. O processo não mudou. Mudou o negócio, que era o objetivo.
A saída correta quase nunca é subir de plano, porque o tecto de tempo não se compra: redesenha-se. O padrão que funciona é partir o trabalho em dois cenários — um que recolhe e põe em fila, outro que consome a fila em lotes pequenos com o seu próprio agendamento — para que nenhuma corrida individual se aproxime do limite. É mais trabalho do que arrastar mais um módulo, e é a diferença entre um fluxo que aguenta o crescimento e um que se parte justamente quando o negócio corre bem.
O que o Make faz quando algo falha (e o que não faz por ti)
O Make traz uma rede de segurança que muita gente nem sequer ativa: as execuções incompletas. Quando um cenário rebenta a meio, em vez de perder o dado a plataforma guarda a corrida por acabar para que a possas retomar ou reparar. É uma boa rede e convém usá-la. Também tem bordos, e os bordos são a letra pequena que decide se o teu sistema perde informação.
Esse armazém não é infinito: há um limite por cenário não resolvido — da ordem dos 10 MB — e um tecto agregado por equipa — da ordem dos 500 MB — e as que resolves são apagadas automaticamente ao fim de 30 dias. A parte incómoda chega quando esse armazém enche, porque então o comportamento depende de uma caixa que alguém marcou há meses sem pensar: se a perda de dados estiver desativada, o Make desativa o cenário; se estiver ativada, o Make continua a agendar corridas e descarta a execução incompleta que não cabe. Nenhuma das duas opções é boa. Uma pára-te o negócio, a outra esvazia-o em silêncio.
| O que falha | O que o Make faz por omissão | O que tens de decidir tu |
|---|---|---|
| 429 da API de destino (rate limit) | A execução morre; se as incompletas estiverem ativas, o dado vai para lá | Quantas retentativas, com que espera, e o que acontece quando se esgotam |
| 503 transitório do outro lado | O mesmo: pára onde estava | Se retentas ou se o registo vai para uma fila de revisão humana |
| Dado inesperado (campo vazio, formato estranho) | Nada de especial: rebenta o módulo que lhe tocar | Validar à entrada e encaminhar o caso estranho para uma pessoa |
| Armazém de incompletas cheio | Desativa o cenário, ou descarta a execução, conforme uma caixa | Qual dos dois males preferes — e como ficas a saber que aconteceu |
Há um segundo erro clássico, e é autoinfligido: a retentativa sem tecto. Um gestor de erros que retenta indefinidamente contra uma API que devolve 429 não arranja nada; queima operações a ritmo de incêndio e bloqueia o cenário. Toda a retentativa precisa de três coisas — um número máximo, uma espera crescente entre tentativas e um destino final para o registo quando se esgotam — e esse destino final é normalmente uma pessoa. Desenhar essa saída sem a transformar num estrangulamento é exatamente o problema do humano no ciclo.
Versionamento: o cenário que ninguém sabe quem mexeu
O Make não traz controlo de versões ao estilo de um repositório de código. A prática generalizada, e a que quase toda a gente recomenda, é clonar o cenário antes de lhe mexer e testar sobre dados de desenvolvimento. Funciona enquanto fores um. Assim que são três, a pasta enche-se de cópias com nomes como «Encomendas v2 FINAL (o bom)» e ninguém sabe qual está viva.
O custo real de não versionar não é a desarrumação, é que perdes a capacidade de responder a três perguntas no dia em que algo se parte: o que mudou, quem mudou e como se volta atrás. Sem essas três respostas, cada incidente vira arqueologia. E a arqueologia, em produção, paga-se em horas de gente cara enquanto o processo está parado.
- Um blueprint exportado por cada alteração. O Make deixa exportar o cenário em JSON: mete-o no repositório da empresa. É o diff que a plataforma não te dá.
- Nomenclatura aborrecida e estrita. Um nome por cenário, um sufixo para a cópia de trabalho, zero adjetivos. «FINAL» não é um estado.
- Um ambiente de testes a sério, com credenciais próprias e dados falsos. Testar em produção sobre um registo real é exatamente o que parece.
- Uma pessoa que promove. Qualquer um propõe uma alteração; uma só a passa a produção. Não é burocracia: é saber a quem ligar às três da manhã.
- Um registo de alterações de duas linhas. Data, o que se mexeu, porquê. Ninguém o lê até ao dia em que precisa, e esse dia paga todos os anteriores.
Isto não é mania de engenheiro: é a parte mínima de governação e controlo da automação sem a qual não se pode dizer que um processo está em produção. Um fluxo que move dinheiro ou dados de clientes e que qualquer pessoa pode editar a quente sem deixar rasto não é um sistema: é um risco com uma interface bonita.
A fatura sobe justamente quando fazes bem
Aqui está a armadilha que leva muita gente a deixar o cenário frágil de propósito, mesmo que não o diga em voz alta. O Make cobra por operação: cada módulo que processa dados passa pela caixa. E tudo o que acabámos de descrever — validar a entrada, controlar erros, retentar com espera, registar o que aconteceu, avisar um humano quando o caso é ambíguo — são módulos. Endurecer o fluxo multiplica o consumo do mesmo processo sem automatizar um único caso novo.
O resultado é um incentivo perverso perfeitamente mensurável: a plataforma cobra-te mais por tornares o sistema mais robusto. Não é maldade do Make, é a consequência aritmética de cobrar por passo, e acontece a qualquer ferramenta com esse modelo. A comparação completa das três unidades de faturação — passo, operação e execução — está em o preço das ferramentas de automação, e é a leitura que transforma este guia numa decisão com números.
Consequência prática: quando projetares o custo de levar o protótipo a produção, não projetes o cenário de hoje. Projeta o cenário endurecido, que terá o triplo dos módulos, ao volume que esperas daqui a doze meses. Se essa conta sair mal, o problema já não é de configuração; é de ferramenta, e toca a conversa Make contra n8n.
Três saídas: endurecer, partir ou mudar o motor
Nem todos os cenários que encravam precisam do mesmo, e errar o diagnóstico é caro nas duas direções: migrar por gosto custa semanas, ficar por inércia custa quedas. Estas são as três saídas reais e o sinal que as distingue.
| A tua situação | O que fazer | Sinal de que é o teu caso |
|---|---|---|
| O cenário está correto mas é frágil | Endurecê-lo onde está: validação, tratamento de erros, alertas, logs | Falha pouco, mas quando falha ninguém dá por isso até um cliente perguntar |
| O cenário sufoca por tamanho | Parti-lo: um que põe em fila, outro que consome por lotes | Tocas no tecto de tempo, ou o iterador cresce todos os meses |
| O modelo de preço está a castigar-te | Mudar o motor para uma ferramenta que cobra por execução | A fatura sobe e não acrescentaste um único processo novo |
As três exigem a mesma decisão prévia, e é de organização, não de tecnologia: alguém tem de ser dono do fluxo. Um processo automatizado sem dono degrada-se sozinho, porque as APIs mudam, os formatos deslocam-se e os casos estranhos aumentam com o volume. Essa disciplina — quem olha para quê, de quanto em quanto tempo e com que alertas — é o que descreve a manutenção das automações, e é a diferença entre um sistema que envelhece bem e um que um dia simplesmente deixou de correr sem ninguém reparar.