Chamar 5 APIs de rede social em sequência parece um loop de 20 linhas: até a primeira quinta-feira de pico: uma rede falha, outra estoura rate limit, o post vai duplicado e o cliente pergunta por que saiu no Facebook e não no Instagram. A diferença entre o toy e o sistema de produção é arquitetura.
Por que a chamada direta em sequência quebra
- Falha global: um erro no meio da sequência derruba o post inteiro: ou duplica o que já saiu.
- Picos de publicação: agendamentos concentrados no mesmo horário saturam conexões e rate limits.
- Falha parcial: uma rede publica, outra falha: e ninguém sabe o estado real de cada destino.
- Rate limits distintos por rede e por conta: o loop ignora que cada API tem regra própria.
A arquitetura que resolve: publicação assíncrona com filas
O princípio: separar a CRIAÇÃO do post da EXECUÇÃO da publicação. Quando o usuário clica em publicar, o sistema cria um job por destino (uma rede = um job), enfileira e um worker processa em segundo plano: atualizando o status de cada destino independentemente. Falha no Instagram não afeta o LinkedIn: cada job vive a própria vida.
Modelo de dados mínimo
| Tabela | O que guarda |
|---|---|
| usuários / contas sociais | Quem publica e quais contas conectadas (por rede) |
| posts | Conteúdo criado + mídia + estado geral |
| destinos de publicação | Onde cada post vai (perfil/página/grupo): separado do usuário |
| jobs | Um job por destino: post, destino, tentativas, próxima execução |
| resultados | Saída de cada job: URL publicada, ID da rede, erro se houver, chave de idempotência |
Estados de job que evitam 90% dos chamados de suporte: queued → processing → published | failed_retryable | failed_action_required | cancelled. O 'action_required' é o que manda o usuário reconectar a conta expirada: em vez de um erro genérico que ninguém sabe resolver.
Boas práticas que evitam os erros clássicos
- Retries seletivos: backoff exponencial para falhas temporárias (rede, rate limit); NUNCA retry automático para autorização expirada ou mídia inválida: isso é ação do usuário.
- Rate limit por rede: pause apenas os jobs da rede afetada: as outras seguem publicando.
- Chaves de idempotência: o mesmo job reprocessado não pode publicar o post duas vezes.
- Inspect the result: status HTTP 200 não garante publicação: leia o corpo da resposta da rede antes de marcar 'publicado'.
- Monitore duas camadas: operacional (fila, latência, taxa de falha) e de usuário (taxa de sucesso, reconexões necessárias).
Construir OAuth e normalização próprios faz sentido quando publicação social É o produto. Para todo o resto, uma camada unificada (autenticação e normalização por rede) reduz semanas/meses de construção e manutenção para dias: liberando o time para a lógica de filas e a experiência do usuário, que é onde está o valor.
Essa é a mesma arquitetura por trás da camada de distribuição social que a M&C opera: um conteúdo, múltiplos destinos, cada publicação com estado próprio e visível: sem post duplicado, sem rede esquecida.