System Design/04 - Cloud Design Patterns/Design & Implementation2 min
Pipes and Filters
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Decompor um processamento complexo numa sequência de etapas independentes, ligadas por canais.
entrada → [validar] → [enriquecer] → [transformar] → [gravar] → saída
Cada filtro faz uma coisa, não conhece os vizinhos, e comunica-se apenas pelo formato de mensagem do canal.
Trade-offs
O ganho é composição e escala granular: filtros podem ser reordenados, reutilizados em outros fluxos, e escalados independentemente. Se transformar é dez vezes mais lento que os outros, escala-se apenas ele — algo impossível num processo monolítico.
Também melhora a testabilidade: cada filtro é uma função com entrada e saída definidas.
Os custos:
Latência acumulada. Cada canal adiciona serialização, transporte e desserialização. Para um processamento que levaria 10 ms num único processo, dividir em cinco etapas pode custar mais em transporte do que em trabalho.
Estado é difícil. Filtros idealmente são sem estado. Quando uma etapa precisa de contexto das anteriores, ele viaja na mensagem — que engorda — ou vive fora, o que quebra a independência.
Tratamento de erro distribuído. Uma falha na etapa 4 exige decidir o que fazer com o trabalho parcial das etapas 1 a 3. Sem Compensating Transaction ou idempotência, o resultado é inconsistência silenciosa.
Observabilidade. Sem correlation ID atravessando o pipeline, rastrear um item específico é impraticável.
E, como todo pipeline, ele anda na velocidade do filtro mais lento. Identificar e escalar o gargalo é a atividade permanente de quem opera um.
Exemplo prático
Processamento de pedidos:
[receber] → [validar] → [checar fraude] → [reservar estoque] → [cobrar] → [notificar]
checar fraude chama um serviço externo e leva 800 ms; os demais levam ~20 ms. Escalar só esse filtro (20 instâncias contra 2 dos outros) equilibra o pipeline.
Quando cobrar falha, o estoque já foi reservado — e é aí que o desenho é testado. A resposta correta é uma compensação explícita que libera a reserva, disparada pela falha. Sem ela, o estoque fica reservado para um pedido que nunca existirá, e o problema só aparece quando o produto "acaba" sem ter sido vendido.
Relacionado
Parte de Design & Implementation · roadmap.sh/system-design