Mapa de um pipeline de lastros
Manutenção leve e catalogação de um pipeline de dados de lastros que eu não construí: inventário e diagramas do código PySpark, Kafka e Django para ligar a ele os projetos que eu fazia para o mesmo cliente. Cliente anonimizado.
- categoria
- profissional
- stack
- PySpark
- Python
- Kafka
- Django
- AWS
- SQL
Contexto
Suíte de operação financeira em três repositórios, com backend Django, frontend Vue e pipelines PySpark, construída por outra equipe antes de eu chegar. Os projetos que eu fazia para o mesmo cliente precisavam ler e alimentar essa suíte, e não havia um mapa dela.
Pressão e restrição
Ligar meus projetos a um sistema em produção que eu não escrevi, sem mudar o comportamento dele, num fluxo que roda em staging, homologação e produção.
Decisão
Antes de escrever integração, catalogar o que já existia. Na manutenção, mexer pouco e só onde o catálogo mostrava o efeito da mudança.
Execução
Li os três repositórios e montei o inventário dos tópicos Kafka e consumers por domínio, da fila de erro (DLQ), das camadas silver e gold do PySpark e dos pontos de entrada e saída no S3 e no SQS, com diagramas do caminho de um evento da entrada ao relatório. A manutenção foi leve e pontual.
Como sei que funcionou
O catálogo e os diagramas foram a base das integrações dos meus projetos com a suíte.
impacto
Meus projetos com esse cliente passaram a conversar com a suíte a partir de um mapa, não por tentativa. O sistema e as decisões de arquitetura dele são da equipe original; cliente e regra de negócio ficam de fora por confidencialidade.
o que transfere
Em sistema herdado, o mapa vem antes da integração: catalogar tópicos, filas e camadas custa pouco e mostra onde uma mudança pequena tem efeito grande.