A unificação da stack do VivaReal e Zap Imóveis
Ué, mas não são só três páginas?
Essa é a frase que eu falei brincando logo quando cheguei no VivaReal em meados de 2016. Afinal, aparentemente, ele é basicamente a home, a busca e o detalhe de um imóvel, certo?
Nesse artigo, eu vou contar um pouco em como ficou a nossa estrutura após o fim da integração dos sistemas do VivaReal e do Zap Imóveis, além de dar um overview de como foi esse processo na engenharia.
Integração dos sistemas?
Quando aconteceu a fusão, o grupo começou a olhar os sistemas de cada uma das duas empresas, e obviamente, quase tudo era bem semelhante, pois elas eram exatamente o mesmo modelo de negócio.
Com isso, foi natural que a empresa inteira chegasse a uma reflexão: fazia sentido criar um ecossistema único? A resposta foi sim, e a partir dali começou toda uma jornada de como faríamos isso.
Depois de quase 2 anos e meio dessa temerosa integração, podemos dizer que finalmente ela chegou ao fim em junho/julho de 2020 (com umas pequenas rebarbas resolvida em agosto).
Desde o seu princípio no começo de 2018, tudo aquilo que parecia tão distante e nebuloso aconteceu: nem mesmo o bancão do zap está aqui pra contar a história.
Mas agora você pode estar pensando…. tinha tanta coisa assim?
O legado do VivaReal
Quando cheguei no VivaReal, era um momento onde os times estavam começando a desenhar o que seria a evolução dos sistemas que existiam na época: aquele momento clássico de quebrar os grandes monolitos e tudo mais.
O VivaReal surgiu em 2009 e teve um crescimento muito rápido, com parte de seu código sendo desenvolvido na Colômbia. Em 2016, o codebase ainda tinha muita coisa dessa época, inclusive com partes do código em espanhol.
O desenvolvimento e reestruturação desses novos sistemas do VivaReal foi evoluindo no decorrer de 2017, e esse “novo VivaReal” foi tomando forma própria, criando a base da big picture da engenharia que tínhamos como objetivo futuro.
Foi então que no final de 2017 chegou a notícia: VivaReal e Zap Imóveis iriam se juntar a partir de 2018.
O legado do Zap Imóveis
Pra quem não sabe, o Zap Imóveis, um dia foi apenas ZAP, que por sua vez um dia foi Planeta Imóvel.
O Planeta Imóvel foi criado em 2000, no início da internet no Brasil, e foi o pioneiro nesse modelo de negócio por aqui.
O ZAP (batizado em 2007) era um portal de classificados para coisas em geral (veículos, imóveis, empregos) e em 2010, ele se tornou o Zap Imóveis.
E o Zap Imóveis foi evoluindo em cima dessa estrutura montada lá atrás. Ou seja, componentes periféricos, como visual crons e API’s, eram moldados para falar diretamente com esse grande banco de dados, que continha suas regras de negócio em milhares de procedures e centenas de tabelas.
Os desafios
Integrações entre sistemas são extremamente complexas.
No nosso caso, era uma integração de dois ecossistemas inteiros com tecnologias bem diferentes.
Essas foram algumas das questões controversas que enfrentamos:
- Como unificar contas e contratos vigentes (imobiliárias, incorporadoras, corretores e proprietários) num CRM novo, sendo que cada empresa utilizava um CRM diferente, com suas próprias regras de negócio?
- Como centralizar todos sistemas de backoffice de operações internas das diferentes áreas em um só, se os sistemas unificados ainda não existiam?
- Como fazer todos nossos imóveis serem buscados numa mesma plataforma de busca e recomendação, mas com diferentes pesos e ranking por origem?
- Como manter o SEO das URL’s retrocompatíveis com as que o google já tinha indexado dos portais? Um dia os sistemas seriam únicos, mas como fazer uma diferenciação entre seus conteúdos?
- Como vamos unificar os dois inventários de imóveis, com suas imagens e geolocalização, em um lugar só, segregado por portal? E qual vai ser o modelo da entidade de imóvel, sendo que cada portal tinha o seu próprio modelo e regras de negócio?
- Como vamos manter as integrações com softwares parceiros, uma vez que a integração deles são específicas por portal?
- Como enviar e consolidar todos contatos de interesse em imóveis gerados para anunciantes sendo que não tínhamos um identificador em comum?
- Como fazer a migração de pagamentos e assinaturas de uma plataforma para outra, que utilizava outro gateway e modelos de cobrança? Como unificar o faturamento das duas empresas? Como ter uma regra de inadimplência única?
- Como fazer as diversas interfaces de usuário conversarem com as mesmas API’s, inclusive de autenticação, em seus diversos clientes: iOS, Android e Web nos dois portais e nas plataformas de anunciantes? Como ter um único design system de componentes para essas interfaces?
- Como lidar com apps Android e iOS das duas empresas, com codebase espalhado e app stores separadas?
- Como fazer um plataforma do zero para os clientes conseguirem fazer a gestão, acompanhar seus relatórios, acessar seus dados de cobrança em um só lugar? O que iríamos fazer com o histórico de ambas as empresas?
- Como fornecer para a empresa uma única fonte de dados confiável para todo tipo de análise?
- Como fazer tudo isso da maneira mais transparente (se possível, invisível) para os usuários dos sites, pros nossos clientes e todas as outras áreas da nossa empresa, sem quebrar o nosso negócio?
As premissas
As questões acima acabaram sendo respondidas de fato durante o processo de integração e algumas premissas nos guiaram para mantermos o foco no nosso objetivo:
- A arquitetura e plataforma do VivaReal seria a base dessa stack unificada. Os sistemas existentes começaram a ser evoluídos e outros foram criados para suportar as novas regras de negócio, para ambas marcas, seguindo os mesmos guidelines de qualidade e desenvolvimento que já tínhamos.
- Colocamos os sistemas do Zap Imóveis em freeze. Apenas bugfixes, pequenas manutenções e ajustes visando a integração foram desenvolvidos.
- As entregas ocorreriam de maneira gradual, portanto foi preciso preparar uma stack híbrida. Isso foi feito desenvolvendo sistemas perecíveis (do qual não nos orgulhamos), que foram necessários para ficar sincronizando as coisas que estávamos construindo com sistemas do zap imóveis e vice-versa. Com o fim da integração todos foram desligados, sem dó.
- Features e até produtos que “não se pagavam” (pouca utilização/alto custo de manutenção/etc) seriam descontinuados e não foram migrados.
As viradas
O que seriam das migrações sem as viradas de chave, né?
Como o Márcio disse, existem sim, migrações sem sofrimento. Usamos muitos testes A/B, split tests, chaveamento na borda e feature toogle (no artigo é detalhado o fim de um dos legados do VivaReal).
Porém existem migrações que necessitam de coisas que vão além dos limites do software. Geralmente elas tem uma janela bem específica (um dia ou uma semana) e não tem volta (eu chamo de “deploy sem rollback”).
E porque elas não tem volta? Porque ela envolve diversos fatores externos (como um comunicado com os clientes avisando que a forma de pagamento irá mudar, por exemplo), deploys casados de vários sistemas que vão ter um funcionamento diferente ou até mesmo um fim de um contrato com serviço terceiro que não será renovado.
Ou seja, elas precisam ser praticamente perfeitas. Todas as viradas desses tipo foram feitas com muito teste de ponta a ponta em modo war room e sempre com planos de contingência (nem sempre elegantes). Utilizamos waves de migração em grupos lógicos: primeiro só uma certa amostra, depois outra leva, e assim íamos abrindo essa porteira pouco a pouco. Uma virada big boom catastrófica pode ter consequências irreversíveis.
Stack Unificada
E o que tem nessa stack unificada VivaReal e Zap Imóveis?
Bom, antes de tudo, temos que dar visibilidade de alguns números…
Começando com a entidade principal no nosso ecossistema: uma listing. Uma listing é o anúncio de um imóvel. No momento que esse artigo está sendo escrito (setembro 2020), existem mais de 7.5 milhões de listings ativas nos portais (no total temos mais de 11.5 milhões de listings indexadas).
Como comparação, temos provavelmente mais listings no Brasil que o Airbnb tem no mundo todo (que diz ter mais de 7 milhões no início de 2020 aqui).
Essas listings estão espalhadas por mais de 3200 cidades, ou seja, temos presença em praticamente 65% do total de todas as 5000 cidades do país (contabilizando mais de 50 mil bairros).
Isso reflete na nossa busca: picos de mais de 10 milhões de buscas e mais de 110 milhões de outros eventos são produzidos por dia, que servem para alimentar nossos sistemas de recomendação real-time, ranking e o clickstream em nosso data lake.
Nosso negócio é muito ligado ao SEO, portanto para cada listing são geradas dezenas de variações de URL’s compatíveis. E para cada busca também. Nesse exato momento temos mais de 60 milhões de chaves de slugs que auxiliam o site a redirecionar para as URL’s corretas e renderizar os metadados de cada página, além de gerar todo sitemap.
Falando em renderização, temos o mesmo render engine para os dois portais, que suporta dois tipos de templates. Ele, junto com os apps, consomem a nossa API de orquestração (que expõe e padroniza nossos serviços internos para apps e portais). Ela gera picos de +1200 req/s para nossos serviços internos via http e gRPC e +4000 req/s direto no cache da aplicação.
Obviamente essas partes do sistema expostas para o mundo, além do cache da aplicação, tem o cache na borda, que recebe quase 400 milhões de requests por dia. Em agosto batemos 12 bilhões de requests na borda, com ~54% de HIT no cache.
Grande parte desse HIT de cache vem de nossas imagens. Por dia temos mais de 1 milhão de criação de novas novas imagens, que precisam ser baixadas da fonte original e persistidas na nossa CDN. Assim como criamos fotos novas, deletamos as que não usamos (com o mesmo volume praticamente).
Essas imagens passam por vários tratamentos para comportar todos os tamanhos que precisamos e temos o desafio de qualificar e rotular elas em real time. E nós temos muitas imagens: estamos com mais de 250 milhões de imagens em nosso storage.
Mas como todas essas listings e imagens chegam até os portais? Provemos diversas integrações com outros softwares, onde diariamente recebemos milhões de atualizações de listings por dia através de um workflow de processamento via feeds. Esse workflow aceita múltiplos formatos de input, além de termos criado um formato que se tornou o padrão no mercado: o VRSync.
Para os anunciantes que não usam softwares de integração, nós fornecemos uma única plataforma própria para visualizar e editar seus anúncios, gerenciar seus pagamentos e integrações, relatórios de desempenho, usuários e permissões, estatísticas de performance e todos os seus leads.
Leads é outra entidade muito importante no nosso ecossistema: é o início de um contato entre um anunciante e um consumidor. E assim como suportamos integrações de listings, suportamos integrações de leads entre diferentes softwares e garantimos que sua entrega seja feita também por e-mail, push notification ou via chat. Recebemos mais de 4.5 milhões de leads em agosto 2020.
Claro que para segurar todo esse negócio, existe o CRM onde todos esses contratos e vendas acontecem. São sistemas preparados para o time comercial e operacional conseguir operar para atender imobiliárias, corretores e incorporadoras. Nessa mesma plataforma fica também todos os sistemas de atendimento ao consumidor, com bots de atendimento e relatórios de desempenho.
Também temos o e-commerce onde um proprietário pode anunciar seu anúncio online e fazer a gestão do listing direto na área logada do site, usando um modelo similar a uma assinatura.
Devido a essa flexibilidade, a plataforma de pagamentos tem um comportamento um pouco atípico: suportamos desde pagamentos de cartão de crédito de R$20,00 até boletos únicos de mais de R$100.000,00.
Por fim, toda essa arquitetura de micro serviços rodam em uma única conta da AWS e em um único cluster de kubernetes, de uma maneira bem eficiente. Tudo isso gasta bem menos (quase metade) que apenas o VivaReal chegou a gastar a 3 anos atrás (em dólares).
Existe vida pós integração?
A nossa estratégia foi muito agressiva em relação a integração e ao fim dos nosso legados, pois entendemos que ela permitia e justificava a construção de um ecossistema novo sem amarra nenhuma com o passado.
Fazer essa ruptura não foi NADA fácil, porque não envolvia somente regras de negócio antigas ou sistemas obscuros, e sim todo uma nova maneira de pensar . Precisamos muitas vezes parar e falar “Ok, isso era assim. Agora isso não existe mais”. Vários mitos caíram por terra durante esse processo.
Como o Luiz escreveu 4 anos atrás (no início dessa jornada no antigo VivaReal), no artigo Arqueologia de Código Desvendando fósseis, “O código de hoje é o legado de amanhã”.
Legados contam a história de uma empresa, de ciclos e de pessoas. Eu já vi softwares legados que tinham a sua beleza. Um legado que simplesmente funciona em produção sem problemas (aqueles você até esquece que existe) tem sim o seu valor. E claro, tem o outro lado, que o legado é uma dor constante e quanto mais enraizado ele está na empresa, mais difícil é lidar com ele.
Uma arquitetura de software é a representação idêntica de uma organização e dos times que a desenvolvem e os legados demonstram isso em suas linhas de código e estruturas. A partir do momento que se toma uma decisão de matar um legado, você tem que comprar essa briga até o fim, sabendo das possibilidades de você sofrer um ou vários rebotes — e eles provavelmente virão.
A gente acabou com todos sistemas legados do VivaReal e do Zap Imóveis nesse processo de integração. Apagamos MUITA COISA durante esse processo inteiro. Centenas de repositórios foram arquivados e, com eles, centenas e centenas de milhares de linhas de código foram deletadas. Na conta da AWS do Zap Imóveis não restou praticamente nada (só alguns buckets de histórico). Tudo o que está em produção hoje foi construído entre 2017 e 2020*.
Fazer tudo isso não seria possível sem toda a experiência, pragmatismo e talento da engenharia, confiança total da gestão em toda tomada de decisão, além da flexibilidade de produto, design e todas áreas da empresa nesse período tão sensível e difícil.
Foi preciso também bastante maturidade para entender que planos iriam falhar e tudo bem desistir dele no meio do caminho e seguir por outro. Alguns componentes foram deprecados antes mesmo de subirem para produção. Deixamos o orgulho e o apego de lado e vimos alguns sistemas construídos por nós sendo destruídos por uma causa maior.
No fim, temos um sentimento gratificante e um privilégio de ter passado pelo começo-meio-fim de um mega integração de ecossistemas, mas fica a pergunta: e agora?
A evolução
Agora que temos um ambiente controlado, enxuto e bem mais simples, podemos evoluir os produtos das duas marcas sabendo exatamente como todas engrenagens interagem e o mais importante: o porquê elas existem.
Já sabemos o que precisamos melhorar desse “novo legado” que construímos, afinal software é algo vivo: as coisas mudam de contexto, de sentido, ganham outras responsabilidades ou simplesmente ficam datadas — e ainda bem que é assim.
Afinal, não são só três páginas.
(*pra ser justo: existe uma única API do VivaReal pré-2017 que se mantém até hoje por ter um legado estrutural — e finalmente vamos atacar isso)
