Contato
Pipeline ETL de sindicação de anúncios imobiliários (alias Ligneurs)

Pipeline ETL de sindicação de anúncios imobiliários (alias Ligneurs)

Pipeline ETL do PIM Akeneo aos portais imobiliários - entrega multi-formato (XML, CSV, JSON) ao longo de 4 anos de operação continua.

Janeiro 2019 - 2023
~4 anos
Technical Lead depois Project Manager
Groupe Pichet
PHPSymfonyAkeneo PIM v2REST APIXMLCSVJSONFTP/SFTPGitLab CIDockerKubernetes (K8s)MySQL

Portais parceiros

Várias dezenas

Migrados, integrados e mantidos

Formatos de exportação

3

XML, CSV, JSON

Duração do projeto

~4 years

Evolução continua

Disponibilidade

99.5%+

Em 4 anos de operação continua

Apresentação

Definição e escopo do projeto

Visão geral do sistema

O sistema "Export Ligneurs" e o motor de distribuição automatizada de anúncios imobiliários do Groupe Pichet. Ele extrai dados de programas e lotes do PIM Akeneo, transforma-os no formato específico exigido por cada parceiro (XML, CSV ou JSON) e os exporta automáticamente para as plataformas de distribuição imobiliária.

O sistema constitui o elo crítico entre os dados de produtos da empresa e sua visibilidade comercial: cada anuncio imobiliário publicado nos grandes portais franceses (SeLoger, LeBonCoin, BienIci, LogicImmo...) passa por este pipeline. Qualquer interrupção ou inconsistencia de dados se traduz diretamente em perda de leads e oportunidades comerciais perdidas.

Como unico responsavel técnico deste sistema, eu era responsavel por todas as decisões de arquitetura, desenvolvimento, deploy, monitoramento e resposta a incidentes - com responsabilidade total sobre um pipeline que alimentava um volume estimado de ***K euros/mes em aquisição de leads.

Natureza

Pipeline ETL automatizado (Extract-Transform-Load) para distribuição multicanal de anúncios imobiliários

Domínio

Imobiliário / PropTech - B2B (equipes internas, portais parceiros) e B2C (indireto, compradores potenciais)

Escopo funcional
  • Extração automatizada de dados da API REST PIM Akeneo v2
  • Transformação no formato específico de cada parceiro (XML, CSV, JSON)
  • Entrega automatizada por FTP/SFTP para várias dezenas de plataformas parceiras
  • Adaptação multi-formato de imagens (4/3, 16/9, panoramico, quadrado)
  • Mapeamento de tipologias imobiliárias (apartamento, casa, duplex, triplex, estudio, T1-T5+)
  • Monitoramento de execuções com alertas por email e sistema de monitoramento centralizado
  • Capacidade de ativação/desativação individual por parceiro
  • Algoritmo de matching SKU para programas reais vs. programas criados manualmente no PIM
Arquitetura do sistema
Export Ligneurs - Visão geral da arquitetura do sistema
Escolhas tecnológicas e justificativas

Estado da arte em 2019

Stack alinhada com o padrão de integração B2B da época: ETL batch e FTP/SFTP eram a norma antes da generalização de webhooks e arquiteturas event-driven.

PHP / Symfony

Coerente com o ecossistema backend existente. O componente Symfony Console oferecia um framework sólido para execução de comandos batch agendados.

Akeneo PIM v2

Escolha estratégica da empresa para gestão do catalogo de produtos. Sua API REST fornecia acesso estruturado a todos os dados de programas e lotes com endpoints versionados.

Docker / Kubernetes

Cada job de exportação isolado em seu próprio container, evitando conflitos de recursos entre módulos parceiros. K8s no AWS EKS gerenciava scheduling e recuperação automática de jobs falhos.

GitLab CI

Automatização do ciclo build-test-deploy para cada módulo parceiro de forma independente, permitindo deploys direcionados sem impactar outros feeds ativos.

Objetivos, Contexto, Desafios e Riscos

Visão estratégica e restrições

Objetivos
  • 1Migrar todos os feeds de exportação do antigo PIM v1.4 para o novo PIM v2 Akeneo
  • 2Executar a migração parceiro por parceiro com validação de negócios a cada etapa
  • 3Verificar a consistencia dos dados entre o PIM fonte e os feeds enviados aos portais
  • 4Gerenciar as especificidades de cada portal (formatos de imagem, tipologias, campos obrigatórios)
  • 5Automatizar a supervisão dos feeds (alertas de erro, relatorios de execução)
Contexto

O projeto foi iniciado durante a transferencia de conhecimento de Andoni L. em janeiro de 2019. O sistema existente funcionava no antigo PIM v1.4 e precisava ser totalmente migrado para o PIM v2 Akeneo, mantendo o serviço continuo para todos os portais parceiros.

A migração precisava ser realizada portal por portal - cada um com suas próprias especificações de formato, campos obrigatórios, restrições de imagem e mapeamentos de tipologias - tornando impossível uma migração "big bang". Cada parceiro exigia validação individual pelas equipes de negócios antes de entrar em produção.

O sistema fazia parte de um ecossistema de dados mais amplo: upstream, os dados vinham do software de contabilidade e dos ERPs internos alimentando o PIM, enquanto downstream os feeds conectavam-se a uma centena de fornecedores de leads gerando um volume estimado de 1 lead a cada 2 segundos em todos os portais.

Desafios

Os portais imobiliários parceiros (SeLoger, LeBonCoin, BienIci...) sao canais majoritários de aquisição de leads no mercado imobiliário. Qualquer interrupção ou erro nos feeds se traduz diretamente em perda de leads e redução do pipeline comercial. Com várias dezenas de parceiros para migrar individualmente, o projeto exigiu atenção sustentada por vários anos mantendo zero tempo de inatividade nos feeds ativos.

Riscos

Inconsistencia de dados

Risco de publicar preços incorretos, imagens erradas ou imoveis ausentes nos portais - impactando diretamente a confianca dos compradores e os resultados comerciais.

Interrupção de serviço

Qualquer falha de feed significa que os imoveis desaparecem dos portais, causando perda imediata de leads para as equipes comerciais.

Divergência de formatos

Cada portal tem requisitos unicos (proporções de imagem, codigos de tipologia, campos obrigatórios) - uma abordagem generica era impossível.

Instabilidade da API

Problemas de conexão com a API PIM Akeneo podiam bloquear todas as exportações simultaneamente, exigindo gestão solida de erros e logica de retry.

Decisões de arquitetura chave

Arquitetura modular por parceiro

Decisão: Um módulo isolado por portal ao inves de um motor generico

Justificativa: Isolamento de falhas: um bug em um módulo não impacta os outros parceiros. Deploy e teste independente por feed.

Migração progressiva ao inves de big-bang

Decisão: Migração portal por portal com validação de negócios a cada etapa

Justificativa: Raio de impacto limitado a um parceiro por vez, com rollback imediato em caso de problemas.

Processamento batch ETL ao inves de streaming em tempo real

Decisão: Exportações batch agendadas por CRON ao inves de publicação orientada a eventos

Justificativa: Os parceiros consumiam via depositos FTP/SFTP, não webhooks. Tempo real teria adicionado complexidade sem beneficio.

Pre-geração multi-formato de imagens

Decisão: Pre-gerar todas as variantes de formato centralmente ao inves de sob demanda por parceiro

Justificativa: Evita processamento redundante da mesma imagem em multiplos portais e garante conformidade na origem.

Pipeline de dados ETL
Pipeline Extract-Transform-Load para geração de feeds de parceiros

As etapas - O que eu fiz

Progressao cronologica do projeto

Fase 1
Transferencia de conhecimento e migração inicial
Janeiro 2019
  • Tornei-me o unico responsavel tecnico em 2 semanas apos o handover de Andoni L.
  • No lado da migração, entreguei o primeiro lote: SeLoger Neuf, LogicImmo, TULN, Paru Vendu
  • No lado da gestão do projeto, enquadrei o roadmap de migração com as equipes de negocios e defini os marcos de validação parceiro a parceiro
  • Para assegurar as migrações seguintes, implantei uma checklist de aceitação que reutilizei ao longo do projeto
Fase 2
Desenvolvimento de funcionalidades e novas integrações
Junho - Setembro 2019
  • Como Technical Lead, priorizei o backlog de integrações arbitrando entre demandas de negocios, restrições dos parceiros e capacidade tecnica
  • Integrei o portal BienIci com uma adaptação de imagens dedicada
  • No ImmoNeuf, adaptei o feed com uma conversão 16/9 para 4/3
  • No lado da confiabilidade, estabilizei os feeds SeLoger e Knock
Fase 3
Estabilização e correções críticas
Janeiro 2020
  • Implementei garde-fous de validação de preços antes da publicação
  • Para absorver picos de erro na API, introduzi um circuit breaker e retry exponencial nas chamadas a API PIM
  • No lado da observabilidade, adicionei logging estruturado para reduzir o tempo de diagnostico
  • No lado da gestão do projeto, conduzi os post-mortems de incidentes e reportei ao comite diretor as ações corretivas e seus prazos
Fase 4
Novos parceiros e evolução continua
Junho 2020 - 2023
  • Nos novos parceiros, criei do zero as integrações Investimeo e BienIci
  • Como Technical Lead / Project Manager, enquadrei o roadmap plurianual com a direção e negociei com cada novo parceiro o escopo tecnico e os SLA de integração
  • Para a Marketshot, conduzi a remoção limpa do parceiro sem efeitos colaterais nos demais feeds
  • No lado dos incidentes, resolvi as anomalias NEEDOCS, BienIci e Green Valley

Os atores e interações

Com quem interagi diretamente e como colaborei

Coordenação e colaboração

Como unico responsavel tecnico, eu coordenava diretamente com os stakeholders de negocios, fornecedores externos e portais parceiros. Cada migração me levava a definir os criterios de aceitação, pilotar os ciclos de validação e decidir o go/no-go de deploy em produção. Aprendi a traduzir restrições técnicas em termos de negocios e vice-versa para manter todos alinhados.

Andoni L. (Predecessor)·Gaetan B. (Referente de negócios)·Leslie A. (Referente de negócios)·Franck C. (Gerente (N+1))·Sebastien B. (Equipe prestadora)

Os resultados

Impacto para mim e para a empresa

Para mim
  • Assumi a responsabilidade tecnica completa de um sistema critico que impactava diretamente a receita
  • Tomei decisoes de arquitetura autonomas, com responsabilidade total pela confiabilidade e pela qualidade dos dados
  • Ao longo de 4 anos, pilotei este projeto com as equipes de negocios, fornecedores externos e varias dezenas de portais parceiros
  • Mantive o ciclo de vida completo: arquitetura, desenvolvimento, deploy, monitoramento e resposta a incidentes
  • Este projeto mudou minha forma de trabalhar: me colocou em liderança transversal sobre os processos de validação e o onboarding de parceiros
Para a empresa
  • Várias dezenas de portais parceiros migrados do PIM v1.4 para v2 Akeneo sem interrupção de serviço
  • 2 novas integrações de parceiros construidas do zero (BienIci, Investimeo)
  • Vários milhares de anúncios processados diáriamente em todos os portais parceiros
  • 99,5%+ de disponibilidade em 4 anos, tempo medio de resolução de incidentes inferior a 4 horas
  • Tipologias imobiliárias padronizadas em todos os feeds, reduzindo relatos de inconsistencia
Distribuição por tipo de parceiro
Distribuição dos formatos de exportação

O que aconteceu depois

O que aconteceu após a entrega

Evolução do sistema

Resultado imediato: Após a onda de migração de 2019, passagem para fase de manutenção continua com adição de novos parceiros e resolução de anomalias conforme detectadas.

A medio prazo: Resiliencia comprovada ao longo de 4 anos, absorvendo mudancas de formato dos parceiros e evoluções internas do modelo de dados.

Perspectiva de longo prazo: Tornou-se uma peca de infraestrutura fundamental alimentando o pipeline comercial. A arquitetura modular permitiu evoluir para várias dezenas de portais sem redesign, e qualquer desenvolvedor pode adicionar um parceiro seguindo os padrões estabelecidos.

Distribuição do esforco técnico

Meu olhar crítico

Com o recuo, como julgo este projeto

O que funcionou bem
  • Com o recuo, a migração portal por portal se mostrou acertada: risco minimo, validação de negocios a cada etapa, rollback imediato
  • Reivindico a arquitetura modular que implantei: pude adicionar, modificar ou desativar feeds sem efeitos colaterais
  • Gracas ao onboarding que padronizei, a integração de novos parceiros passou de semanas para dias
O que poderia ter sido melhor
  • Com o recuo, eu teria construido um dashboard centralizado em vez de verificar alertas de email individuais
  • Eu tambem teria montado mais cedo testes de integração automatizados por formato de parceiro para detectar regressoes a montante
Se eu tivesse que refazer hoje
  • Em 2026, optaria por uma abordagem event-driven (Kafka/RabbitMQ) em vez de batch CRON, com monitoramento observability-first (OpenTelemetry, Grafana Tempo)
  • Eu montaria um registro de especificações de parceiros desde o primeiro dia para reduzir o tempo de onboarding pela metade
  • Adicionaria testes de integração automatizados contra o schema de cada parceiro antes do deploy
  • Construiria um dashboard de monitoramento centralizado em tempo real em vez de depender de alertas por email
Os ensinamentos duradouros que este projeto me trouxe
  • Levo como aprendizado que em sistemas multi-parceiros nao existe "solução universal" - cada integração tem suas restrições
  • Aprendi que projetos de longo prazo exigem mentalidade de manutenção desde o primeiro dia
  • Em sistemas criticos para receita, mensurei que a observabilidade importa mais do que prevenir cada falha

Trajetória relacionada

Experiência profissional ligada a está realização

Competências aplicadas

Competências técnicas e humanas aplicadas

Galeria de imagens

Capturas e visuais do projeto

Você tem um Pipeline ETL de sindicação para projetar ?

Entreguei um Pipeline ETL de sindicação multi-portais: extração PIM, transformação multi-formato (XML/CSV/JSON), entrega FTP/SFTP e monitoramento ao longo de 4 anos de operação contínua. Vamos conversar sobre seu contexto.

Entrar em contato