Roteiro de migração de monólitos para microsserviços: modernização de aplicações empresariais

Michael Labutin

5 de abril de 2025 12 min

Se está aqui, é provável que o seu sistema monolítico esteja a tornar-se mais um fardo do que um ativo. Ciclos de lançamento lentos, dores de cabeça de escalonamento e uma arquitetura rígida tornam mais difícil manter o ritmo. Quanto maior for a sua aplicação, mais frustrante se torna. As novas tecnologias não se integram sem problemas, a agilidade é afetada e a fiabilidade começa a diminuir.

Os microsserviços podem mudar as coisas, tornando o seu sistema modular, acelerando as implementações e permitindo-lhe escalar exatamente o que precisa, quando precisa. Mas aqui está o senão: migrar não é apenas dividir o código. Se não o planear corretamente, pode acabar com mais complexidade, pesadelos de integração e custos inesperados.

Neste artigo, vou guiá-lo através de um roteiro real para passar do monólito para os microsserviços. Nada de conversa fiada - apenas passos práticos, lições aprendidas com muito esforço os nossos arquitectos de soluçõese estratégias que realmente funcionam. Vamos mergulhar no assunto.

Passos para migrar de uma arquitetura monolítica para uma arquitetura de microsserviços

Passo 1: Planear uma migração de monólito para microsserviços

Já vi muitas empresas pensarem que os microsserviços são a solução mágica, mas acabaram por se deparar com mais complexidade, fluxos de trabalho quebrados e custos elevados. E se há uma coisa que aprendi, é que saltar diretamente para o lado da tecnologia sem um plano sólido é um caminho rápido para o caos.

É tentador começar a desmontar um monólito e a criar serviços, mas antes mesmo de tocarmos no código, trabalhamos com os clientes para mapear o porquê, quando e como da migração. Desta forma, cada passo em frente fornece efetivamente valor.

Definir os objectivos certos: porque está a migrar

Sempre que os clientes nos contactam para mudar de monólitos para microsserviços, pergunto o que está a motivar a sua decisão de mudar. As respostas variam, mas, na maioria das vezes, ouço que é porque os concorrentes estão a fazer o mesmo. E, sinceramente, esse não é um bom motivo. Saltar para os microsserviços sem um objetivo claro normalmente só leva a mais dores de cabeça, e não a um progresso real.

Por isso, antes de dar o salto, pergunte a si próprio:

O que é que pretende alcançar?
Já considerou alternativas à utilização de microsserviços?
Como saberá se a transição está a resultar?

Se não tiver a certeza - não se preocupe. Ajudamo-lo a definir antecipadamente as principais métricas e os resultados comerciais, para que todas as decisões tecnológicas tenham impacto.

Microsserviços: adequados para todos? Nem sempre

Os microsserviços trazem modularidade, escalonamento independente e inovação mais rápida. Mas não são uma solução milagrosa. Algumas empresas dão-se bem com um monólito, especialmente se a sua aplicação for simples, estável e não mudar muito.

Imagine um pequeno portal de funcionários ou um sistema de inventário que apenas algumas pessoas utilizam. Se estiver a funcionar bem e não necessitar de actualizações constantes, dividi-lo em microsserviços poderia apenas acrescentar uma grande complexidade sem qualquer ganho real.

É por isso que não promovemos os microsserviços só por promover. Em vez disso, analisamos as suas necessidades específicas e verificamos se os microsserviços trarão vantagens reais. Se sim, ótimo - vamos em frente. Se não, encontramos um caminho melhor.

Avaliar o monólito: saber com o que se está a lidar

Depois de decidirmos que os microsserviços são o caminho certo, gostamos de fazer um exame completo do seu sistema para ver como tudo está ligado. Procuramos pontos lentos, potenciais problemas de dependência e onde residem todos os dados críticos.

Saltar este passo é arriscado. Se não souber o que está por baixo do capô, pode acidentalmente derrubar todo o sistema como se fosse um dominó. Ao mapear o que está a funcionar, o que está atrasado e o que pode avariar, criamos um plano de migração inteligente que aborda primeiro as áreas mais críticas, minimizando os riscos, evitando o tempo de inatividade e tornando a transição tão suave quanto possível.

Escolher a estratégia de migração correta

Por esta altura, já deve ter percebido que não sou fã de deitar abaixo um monólito inteiro de um dia para o outro. É demasiado arriscado, demasiado perturbador e, normalmente, não vale a pena o stress. Em vez disso, opto por uma abordagem passo-a-passo que lhe dá ganhos rápidos, mantendo as suas operações estáveis.

Uma das minhas estratégias favoritas é o padrão Strangler Fig, que permite que o sistema antigo e os novos microsserviços coexistam até que você esteja pronto para a transferência completa.

A ramificação por abstração é útil quando é necessário fazer alterações dentro do próprio monólito: adicionamos uma camada, movemos os componentes um a um e retiramos o material antigo sem rebentar com tudo.

Se a fiabilidade for essencial, o Parallel Run mantém ambos os sistemas em funcionamento, comparando os resultados antes de se comprometer totalmente.

E se não for possível mexer no monólito, a captura de dados de alteração permite-nos acompanhar as alterações da base de dados para manter os microsserviços em sincronia.

Não existe um método único que seja o melhor - tudo depende da sua configuração. A nossa equipa também escolhe as partes a migrar primeiro, concentrando-se naquelas que terão o maior impacto. Por exemplo, um sistema de checkout de comércio eletrónico que lida com milhares de encomendas diárias ou um motor de análise de dados que é constantemente atualizado - estes devem ser transferidos mais cedo. Desta forma, obtém benefícios reais rapidamente e mantém as suas operações em ordem.

Alinhamento de equipas e processos

A incorporação de microserviços também significa mudar a forma como as equipas trabalham. Em vez de uma equipe enorme lidando com um monólito, sugiro mudar para equipes menores e multifuncionais, onde cada uma possui um microserviço específico. Desta forma, as decisões são tomadas mais rapidamente e todos sabem exatamente pelo que são responsáveis.

Além disso, os nossos especialistas integram os princípios DevOps e a automatização desde o primeiro dia, para que o lançamento de novas funcionalidades seja fácil e sem problemas.

"Mudar de monólito para microsserviços não é apenas um ajuste técnico - afecta a sua velocidade de desenvolvimento, a estabilidade do sistema e a sua capacidade de escalar. Sem um plano bem elaborado, os custos podem disparar e as integrações podem se transformar em uma verdadeira dor de cabeça. Na Innowise, tornamos a transição suave e eficiente, para que possa manter as coisas ágeis e concentrar-se no crescimento do seu negócio."

Dmitry Nazarevich

CTO

Etapa 2: Identificar e definir os microsserviços

Depois de mapear a estratégia de migração, a próxima grande questão é descobrir como quebrar o monólito em microsserviços sem fazer uma bagunça. Já vi empresas tentarem dissociar tudo de uma vez ou apenas escolher módulos aleatórios para separar. De qualquer forma, isso leva a perda de tempo, dependências quebradas e meses de retrabalho frustrante.

A minha regra geral: manter o foco no negócio. Isso significa que cada microserviço deve corresponder a uma função comercial real e não apenas a um pedaço de código aleatório.

Encontrar limites naturais de serviços

Uma das armadilhas comuns que vemos é a divisão de um monólito em camadas técnicas. Quero dizer, separar o frontend, backend e banco de dados em serviços diferentes. Essa é uma maneira infalível de acabar com microserviços muito acoplados e excessivamente tagarelas que não escalam bem. Em vez disso, usamos o Domain-Driven Design (DDD) e contextos delimitados para dividir as coisas de uma forma que realmente faça sentido.

Tomemos como exemplo uma plataforma de comércio eletrónico. Em vez de a dividirmos num serviço genérico de front-end e num serviço de back-end, separamo-la em funções empresariais reais, como o processamento de encomendas, a gestão de inventário, os pagamentos e a gestão de utilizadores. Cada serviço possui a sua própria lógica e dados, mantendo-os fracamente acoplados para que possam escalar de forma independente e evoluir sem quebrar tudo o resto.

Prioridade aos serviços para migração

Não sou fã da abordagem "big bang". Tentar migrar tudo de uma vez só é pedir para ter problemas. Em vez disso, concentramo-nos naquilo que devemos separar primeiro, analisando:

Dependências mínimas. Os módulos menos emaranhados são mais fáceis de retirar sem partir tudo.
Impacto nas empresas. Tudo o que está relacionado com as receitas ou com a experiência do cliente salta normalmente para a frente da fila.
Mudanças frequentes. Os serviços que são actualizados a toda a hora são os que mais beneficiam da flexibilidade dos microsserviços.

Esta abordagem ajuda-nos a obter ganhos rápidos e a mostrar o valor inicial, tornando mais fácil obter a adesão da equipa. Por exemplo, em um sistema de RH corporativo, o processamento da folha de pagamento pode ser um ótimo microsserviço, já que lida com cálculos complexos e específicos da região. Mas um diretório estático da empresa? Provavelmente não vale a pena a sobrecarga extra e pode ficar no monólito por um tempo.

Evitar a armadilha do monólito distribuído

A última coisa que queremos é converter um monólito em microsserviços e acabar com um monte de serviços que dependem demasiado uns dos outros. Para evitar isso, nós:

Defina APIs claras (REST, gRPC ou orientadas para eventos) para que os serviços comuniquem sem problemas, sem idas e vindas desnecessárias.
Certifique-se de que cada serviço é proprietário dos seus dados - não há bases de dados partilhadas que criem estrangulamentos.
Mantenha as dependências a um nível mínimo para que os serviços possam ser actualizados sem quebrar tudo o resto.

Ao manter os serviços fracamente acoplados, podemos actualizá-los ou modificá-los sem nos preocuparmos com a quebra de tudo o resto.

Conseguir a adesão das equipas

Como disse anteriormente, os microsserviços brilham realmente quando cada equipa é dona do seu serviço do início ao fim. Obtém-se um feedback mais rápido, mais responsabilidade e muito menos idas e vindas entre as equipas. Na Innowise, ajudamos as empresas a configurar suas equipes para que os desenvolvedores, as operações, o controle de qualidade e todos os outros possam trabalhar juntos sem problemas.

Divida o seu monólito em microsserviços e ultrapasse os picos de tráfego.

Etapa 3: Gerir dados em microsserviços

Depois de dividirmos o monólito em micro-serviços, a primeira pergunta é normalmente o que fazemos com os dados? Em uma configuração monolítica, tudo está ligado a um grande banco de dados, que funciona até não funcionar mais. Numa configuração de microsserviços, essa base de dados partilhada torna-se rapidamente um estrangulamento, tornando tudo mais lento e impossibilitando o escalonamento dos serviços de forma independente.

É por isso que eu defendo um modelo de dados descentralizado, onde cada microservice possui seus próprios dados. Feito corretamente, ele permite que cada serviço cresça, se adapte e escale sem tropeçar constantemente um no outro.

Abandonar a base de dados monolítica

Uma base de dados maciça e tudo-em-um pode parecer o caminho mais fácil, mas numa configuração de microsserviços, rapidamente se transforma num estrangulamento. Cada serviço tem necessidades diferentes, e amontoar tudo numa única base de dados apenas cria obstáculos. O escalonamento fica complicado, as dependências se acumulam e até mesmo pequenas alterações podem causar problemas em todo o sistema.

É por isso que nos dividimos em serviços mais pequenos e específicos, para que cada microsserviço:

Controla os seus próprios dados. Acabaram-se os conflitos e as alterações acidentais de outras equipas.
Escala-se por si só. Os serviços não têm de lutar pelos recursos da base de dados.
Pode mudar livremente. A atualização de um serviço não implica o risco de danificar todo o sistema.

Desta forma, tudo é mais flexível, evita que as equipas pisem os pés umas das outras e evita o estrangulamento da base de dados que atrasa toda a gente.

Migração de dados

Mover dadosde um monólito não é um momento de virar a chave. Uma migração sem compromisso é arriscada, então eu prefiro uma abordagem incremental, dividindo-a passo a passo.

Normalmente, isso significa criar novas tabelas ou bases de dados para cada microsserviço e mantê-las em sincronia com o sistema antigo utilizando o Change Data Capture (CDC) ou gravações duplas. Dessa forma, cada serviço assume gradualmente a propriedade de seus dados - sem tempo de inatividade, sem surpresas desagradáveis.

Manter a coerência dos dados

Num monólito, temos uma grande base de dados partilhada e transacções ACID que garantem que tudo é atualizado (ou falha) em conjunto. Mas com os microsserviços, cada serviço gere os seus próprios dados, pelo que as actualizações não acontecem instantaneamente em todo o sistema.

Em vez de actualizações diretas, os serviços falam através de mensagens assíncronas. Digamos que uma encomenda é efectuada, o Serviço de Encomendas dispara um evento e o Serviço de Inventário ouve para ajustar o stock. Esta configuração mantém as coisas a funcionar sem problemas, mesmo que um serviço esteja temporariamente em baixo.

É claro que isso significa lidar com a consistência de forma inteligente. No Innowise, utilizamos operações idempotentes para evitar duplicações, mecanismos de repetição para lidar com soluços e filas de letras mortas para detetar falhas. Desta forma, os seus dados permanecem exactos, mesmo quando as coisas não correm como planeado.

Etapa 4: Implementação e integração

Muito bem, agora que definimos limites de serviço claros e um plano de migração de dados sólido, está na altura de arregaçar as mangas e transformar a estratégia em ação. Vamos ver como é que fazemos isso acontecer.

Criar microsserviços escaláveis e resilientes

A nossa equipa de desenvolvimento constrói microsserviços utilizando ferramentas modernas como o Spring Boot e o Node.js, assegurando que são construídos para escalar e lidar com desafios do mundo real. Para manter as coisas funcionando sem problemas, usamos padrões de design inteligentes, como disjuntores para gerenciar picos de tráfego e degradação graciosa para evitar falhas em cascata. Dessa forma, mesmo que um serviço tenha um problema, o resto do seu sistema continua a funcionar sem problemas.

Manter o legado vivo (por enquanto)

Desligar o monólito de um dia para o outro? Não vai acontecer. Em vez disso, configuramos camadas de integração usando APIs RESTful e corretores de mensagens como RabbitMQ ou Apache Kafka para manter seus novos microsserviços e sistemas existentes em sincronia. Estes actuam como pontes que permitem que tudo comunique suavemente sem quebrar os fluxos de trabalho.

E, quando faz sentido, também integramos gateways de API para impulsionar e proteger as interações, garantindo uma transição suave com zero tempo de inatividade.

Adotar a contentorização

Colocamos os seus microsserviços em contentores com o Docker para que sejam rápidos, flexíveis e fáceis de gerir. Com o Kubernetes a tratar da orquestração, é fácil aumentar a escala durante os períodos de maior atividade ou lançar actualizações em diferentes ambientes. Esta configuração mantém tudo consistente, previsível e rentável, para que as suas operações de TI nunca se sintam como um fracasso.

Automatização com pipelines de CI/CD

A nossa equipa configurou pipelines de CI/CD com ferramentas como Jenkins, GitLab CI ou CircleCI para lidar com testes, construção e implementações automaticamente. Não há mais atualizações manuais ou simulações de incêndio de última hora. Os erros são detectados mais cedo, as versões são lançadas mais rapidamente e o sistema mantém-se sólido como uma rocha.

Deixe-nos criar um ecossistema de microsserviços tolerante a falhas para o seu negócio.

Etapa 5: Teste, implantação e monitorização

Sem as salvaguardas corretas, até o sistema mais bem concebido pode ter estrangulamentos, falhas inesperadas ou simplesmente falhar na pior altura. É por isso que a nossa equipa adopta uma abordagem sem atalhos, automatizando tudo e detectando as questões antes que estas causem problemas reais.

Testes automatizados

Os testes não são apenas o passo final, fazem parte de todo o processo. A nossa equipa de AQA utiliza conjuntos de testes automatizados em várias camadas para detetar falhas antecipadamente, para que nada passe despercebido.

Testes unitários. Cada microsserviço recebe seu próprio check-up com JUnit, Mocha e PyTest. Se algo estiver errado, detectamos imediatamente.
Testes de integração. APIs, dependências e fluxo de dados precisam ser sincronizados. Nossos especialistas usam Postman, REST-assured e WireMock para garantir que isso aconteça.
Testes de contrato. Os microsserviços têm de cumprir as regras. Com o Pact, mantemo-los sob controlo, evitando a quebra de ligações entre serviços.
Testes de ponta a ponta. Executamos cenários reais - desde a interface do utilizador até ao backend - utilizando o Selenium, o Cypress e o Playwright. Desta forma, todo o sistema funciona como esperado.
Testes de carga e de esforço. A nossa equipa leva o sistema aos seus limites com o JMeter, o Gatling e o Locust para ver como se aguenta sob tráfego intenso.

Implantações sem riscos

Ninguém quer que um mau lançamento deite abaixo o seu sistema, frustre os utilizadores ou afunde as receitas. É por isso que a nossa equipa mantém as implementações seguras, controladas e prontas para a reversão com estratégias testadas em batalha.

Canárias libertadas. Em vez de mudar o interrutor para todos de uma só vez, começamos por uma pequena percentagem de utilizadores. Se tudo correr bem, continuamos. Se algo estiver errado, os nossos especialistas corrigem-no antes que alguém se aperceba.

Digamos que uma empresa retalhista pretende lançar um programa de fidelização baseado em pontos, mas o seu sistema de encomendas é demasiado complexo para ser modificado com segurança. Uma empresa de retalho pretende lançar um programa de fidelização baseado em pontos, mas o seu sistema de encomendas é demasiado complexo para ser modificado com segurança. Para jogar pelo seguro, testamo-lo primeiro com um pequeno grupo. Se tudo correr bem, lançamo-lo de forma mais alargada.

Implantações azuis/verdes. A nossa equipa executa dois ambientes ao vivo ao mesmo tempo:
- Blue (versão atual): a versão estável que está em vigor;
- Verde (versão actualizada): a nova versão, testada e pronta a ser utilizada.

Quando tivermos a certeza de que a versão verde é sólida, mudamos o tráfego instantaneamente. Se algo correr mal, voltamos a mudar para a versão azul. Sem tempo de inatividade, sem stress.

Por exemplo, uma plataforma de viagens quer adicionar preços em tempo real, mas mexer no seu sistema antigo poderia destruir as reservas. Em vez de apostar tudo, a nossa equipa opta por uma abordagem azul-verde, enviando primeiro um pequeno grupo de utilizadores para a nova configuração. Se tudo correr bem, mudamos toda a gente. Se as coisas derem para o torto, voltamos atrás instantaneamente.

Sinalizadores de funcionalidades e testes A/B. Por vezes, a implementação para 100% de utilizadores não é a melhor opção. Os sinalizadores de funcionalidades permitem-nos ativar ou desativar funcionalidades de forma dinâmica, para que possamos testar em produção sem afetar toda a gente. Também utilizamos testes A/B para comparar várias versões de funcionalidades em condições reais antes de nos comprometermos com um lançamento completo.

Imagine uma empresa de comércio eletrónico a lançar um motor de recomendação alimentado por IA. Em vez de ligar o interrutor para toda a gente, utilizamos sinalizadores de funcionalidades para o ativar primeiro para os clientes que regressam. Se o envolvimento e as vendas aumentarem, expandimos; se não, desligamo-lo instantaneamente.

Ao mesmo tempo, a nossa equipa executa testes A/B, comparando o sistema antigo com o novo e acompanhando as principais métricas, como o valor do carrinho e as taxas de conversão. Estes dados ajudam-nos a afinar a IA antes de um lançamento em grande escala.

Monitorização proactiva e registo em tempo real

Os microsserviços geram toneladas de dados, portanto, é essencial ficar de olho na integridade do sistema em tempo real. Nossa equipe configura o monitoramento em várias camadas com ferramentas como Prometheus, Grafana e New Relic para rastrear velocidade, uso de memória e erros. Dessa forma, podemos detetar problemas antes que eles se tornem uma dor de cabeça. Usando ELK Stack, Fluentd e outros, também reunimos todos os logs (basicamente, o rasto digital das suas aplicações) num único local, para que nada passe despercebido. E se alguma coisa correr mal, os alertas automáticos levam os nossos engenheiros a tratar do assunto o mais rapidamente possível.

Cópia de segurança e recuperação de dados

Sejamos realistas, nenhum sistema é 100% à prova de falhas. O hardware morre, o software falha e as ameaças cibernéticas não param de evoluir. É por isso que a proteção de dados é uma obrigação. Assim, a nossa equipa define estratégias de cópia de segurança automatizadas para que os seus dados críticos permaneçam seguros e fáceis de recuperar.

Instantâneos automáticos. Usamos o AWS RDS, o Google Cloud SQL e o Azure Backup para tirar instantâneos contínuos do seu banco de dados. Se algo quebrar, você pode reverter instantaneamente para uma versão estável com o mínimo de tempo de inatividade.
Armazenamento geo-redundante. Uma cópia de segurança não é suficiente. Os nossos especialistas distribuem cópias por diferentes centros de dados, pelo que, mesmo que um deles sofra uma avaria ou seja atingido por um ataque informático, os seus dados continuam seguros e acessíveis.
Cópias de segurança incrementais e recuperação pontual. Em vez de efetuar uma cópia de segurança enorme que demora séculos, utilizamos cópias de segurança inteligentes que apenas captam alterações recentes. E com a recuperação pontual, podemos retroceder a sua base de dados para qualquer momento antes de um problema, poupando-o a eliminações acidentais ou corrupção de dados.
Recuperação de desastres. Um plano sólido de recuperação de desastres evita que pequenos problemas se transformem em crises de grande dimensão. Se algo falhar, os sistemas de failover automáticos mudam-no para uma cópia de segurança, para que a sua empresa continue a funcionar sem problemas.

Passo 6: Otimização iterativa e escalonamento

A migração de monólitos para microsserviços não é apenas uma atualização única, eles precisam de cuidados contínuos para terem o melhor desempenho possível. Estamos aqui para o longo prazo, garantindo que sua configuração permaneça ágil, escalone sem problemas e lide até mesmo com as cargas mais difíceis.

Afinação do desempenho

A nossa equipa mantém-se atenta a cada microsserviço, ajustando o código, optimizando as consultas às bases de dados e suavizando a forma como os serviços comunicam para manter tudo a funcionar rapidamente.

Escalonamento inteligente

Ao analisar o tráfego em tempo real e os padrões de carga, os nossos especialistas ajustam os recursos de forma dinâmica, assegurando que os serviços de elevada procura obtêm o impulso de que necessitam sem gastos excessivos.

Melhoria contínua

O seu sistema precisa de crescer com o seu negócio. A nossa equipa acompanha o desempenho em tempo real, ouve o feedback e faz ajustes inteligentes para manter a sua arquitetura segura, eficiente e à prova de bala.

Documentação clara e cristalina

À medida que refinamos e expandimos os seus microserviços, mantemos tudo bem documentado. Desta forma, as futuras actualizações e migrações são fáceis e a sua equipa sabe exatamente o que está a acontecer.

Prepare a sua aplicação empresarial para o futuro com uma migração inteligente de microsserviços.

Modernize seus aplicativos corporativos com as soluções da Innowise

A migração de monólitos para microsserviços é uma medida estratégica para melhorar a agilidade, a escalabilidade e a resiliência. Mas, se o fizer sem um plano sensato, poderá ter de enfrentar tempos de inatividade, fluxos de trabalho interrompidos e custos elevados. Uma migração inteligente requer o estabelecimento de limites de serviço, o tratamento correto dos dados e o seguimento das melhores práticas de segurança e implementação.

Na Innowise, ajudamos as empresas a fazer essa mudança com confiança. Com mais de 18 anos em modernização de software e desenvolvimento, tratamos de tudo, desde a avaliação da sua configuração e a conceção de uma estratégia de migração sólida até à criação de microsserviços escaláveis e à melhoria do desempenho. Os nossos arquitectos de soluções, engenheiros DevOps e programadores utilizam métodos testados e comprovados para reduzir o risco e maximizar o impacto, garantindo que os sistemas da sua aplicação escalam e evoluem com o seu negócio.

Partilhar:

Michael Labutin

Diretor de soluções ERP

O Michael conhece o ERP por dentro e por fora - desde a escolha do sistema certo até à descoberta de como irá funcionar com o resto da sua pilha de tecnologia. É a ele que as pessoas recorrem quando precisam de um ERP para resolver problemas operacionais reais e não para criar novos problemas.

Índice

Contactar-nos

Marcar uma chamada ou preencha o formulário abaixo e entraremos em contacto consigo assim que tivermos processado o seu pedido.

Nome

Empresa

Correio electrónico

Telefone

Mensagem

Envie-nos uma mensagem de voz

Anexar documentos

Enviar ficheiro

Pode anexar um ficheiro com um máximo de 2MB. Formatos de ficheiro válidos: pdf, jpg, jpeg, png.

Ao clicar em Enviar, o utilizador autoriza a Innowise a processar os seus dados pessoais de acordo com a nossa Política de privacidade para lhe fornecer informações relevantes. Ao enviar o seu número de telefone, o utilizador aceita que o possamos contactar através de chamadas de voz, SMS e aplicações de mensagens. Poderão ser aplicadas tarifas de chamadas, mensagens e dados.