O saldo no core diverge do saldo no relatório gerencial. Qual é a fonte da verdade?

Depende da pergunta que está sendo feita, e eu começaria separando dois conceitos. O core é o Source of Record do saldo: é onde o lançamento nasce e é autoritativo sobre o fato. O relatório vem da Source of Truth analítica, que é a visão consolidada, datada e governada usada para decidir. As duas podem divergir sem que nenhuma esteja errada, porque o relatório tem corte temporal, regra contábil e às vezes exclusão de lançamentos em contingência. Então minha primeira ação não é escolher um número, é reconciliar: comparar o mesmo corte, isolar se a diferença é de janela de ingestão, de regra de negócio ou defeito real. Para saldo em tempo real ao cliente, a resposta é o core. Para o número que vai ao regulador, é a visão consolidada, porque ela é auditável e reproduzível. O que não pode existir é divergência sem explicação documentada e sem alerta quando ela sai da faixa esperada.

A diretoria leu sobre Data Mesh e quer adotar. Vocês têm quatro domínios grandes, um time central de dados com fila de três meses e nenhuma plataforma self-serve. O que você recomenda?

Eu concordaria com o diagnóstico e discordaria do primeiro passo. A fila de três meses é sintoma clássico do gargalo central que o Mesh ataca, então a direção faz sentido. Mas os quatro princípios se sustentam juntos: sem plataforma self-serve, descentralizar propriedade só transfere o problema para times que não têm ferramenta, e sem governança federada computacional cada domínio inventa seu padrão de qualidade e de privacidade. Eu começaria pela plataforma e pelo contrato de dados, escolheria um domínio piloto com time de engenharia maduro, como cartão, e trataria uma ou duas tabelas como produto de verdade: dono nomeado, SLA de atualização, schema versionado, catálogo. Mediria tempo de entrega antes e depois. Se o piloto não reduzir a fila, o problema é de plataforma ou de capacidade do domínio, e escalar o modelo só multiplicaria o custo de coordenação.

Data Mesh · tema 35 de 40

Arquiteturas de dados

35 min · 2 vídeos · 14 cards · 2 drill

Por que cai

Arquitetura é onde a banca mede senioridade. Qualquer pessoa lista nomes; o que separa é dizer o que cada escolha custa e em que condição você mudaria de ideia. A pergunta sobre fonte da verdade é a que mais expõe quem nunca conciliou número com área de negócio.

Pré-teste · 1 de 2

responda antes de ver

Qual é o custo característico da arquitetura Lambda?

Quanta certeza você tem?

Vídeo · português · 9 min

Contrasta as duas arquiteturas em pouco tempo e com desenho de camadas. Ignore o recorte de produto Azure e fique com o raciocínio: o que some quando você tira a camada batch.

Em uma frase

Arquitetura de dados é a escolha de onde o dado mora, quem manda nele e quantas vezes a mesma regra é escrita — e cada opção cobra num lugar diferente.

Lambda contra Kappa

Lambda tem duas camadas de processamento. A batch reprocessa o histórico inteiro e produz o número correto, com latência de horas. A speed processa o que chega agora e produz um número aproximado, em segundos. A camada de serviço junta as duas na hora da consulta: histórico da batch, últimas horas da speed.

Kappa elimina a camada batch. Tudo é stream, e reprocessar histórico é reler o log de eventos desde o começo com o código novo.

	Lambda	Kappa
Caminhos de processamento	Dois: batch e speed	Um: stream
Custo principal	A mesma regra escrita duas vezes, que diverge com o tempo	Depender do log reter histórico e reprocessar volume grande por stream
Quando faz sentido	Regra batch complexa que não se traduz bem para stream	Lógica que cabe em stream e log com retenção suficiente

Warehouse, Lake e Lakehouse

	Data Warehouse	Data Lake	Lakehouse
Schema	On write: modela antes de carregar	On read: aplica na leitura	On read com contrato de tabela por cima
Dado que aceita	Estruturado	Qualquer formato	Qualquer formato, com tabelas governadas sobre os arquivos
Transação	ACID nativo	Não tem: escrita parcial é visível	ACID pela camada Delta, Iceberg ou Hudi
Custo de armazenamento	Alto	Baixo (objetos)	Baixo (objetos)
Risco típico	Rigidez e fila de modelagem	Virar pântano sem catálogo e qualidade	Complexidade de operar a camada de tabela
Uso no banco	Relatório regulatório estável	Payload cru de PIX, log, áudio	Tabelas de transação com MERGE e time travel para auditoria

Data Mesh

Mesh responde a um gargalo organizacional: um time central de dados que não dá conta da fila de pedidos de quatro áreas de negócio. Quatro princípios:

1Propriedade descentralizada por domínio: quem gera o dado responde por ele
2Dado como produto: dono, consumidor, contrato, SLA, documentação, descoberta
3Plataforma de dados self-serve: o domínio publica sem depender do time central
4Governança federada computacional: regras globais decididas em conjunto e aplicadas por automação

Um data product não é uma tabela publicada. É uma tabela com dono nomeado, consumidor conhecido, SLA de atualização, qualidade medida e presença no catálogo. O contrato de dados é o acordo explícito de schema, semântica, frequência e política de mudança — o que transforma quebra silenciosa em violação detectável.

Source of Record e Source of Truth

Este par é o que mais derruba candidato, porque parece sinônimo e não é.

Source of Record— O sistema onde o dado nasce e que é autoritativo sobre o fato original. O core bancário é o SoR do lançamento. O sistema de cadastro é o SoR do endereço. Se a base analítica discorda do SoR sobre o que aconteceu, é a base analítica que se explica.

Source of Truth— A visão consolidada, tratada e governada que a organização usa para decidir. A SoT reúne vários SoRs, resolve duplicidade, aplica regra de negócio e corte temporal, e é a referência do relatório e do indicador.

Elas divergem por bons motivos. Corte temporal diferente (o core é agora, o relatório é o fechamento de ontem às 23h59). Regra distinta (lançamento em contingência que a contabilidade ainda não reconhece). Atraso de ingestão. E, às vezes, defeito real.

A resposta profissional não é eleger um número, é reconciliar: comparar o mesmo corte, isolar a causa, documentar a explicação e configurar alerta para quando a diferença sair da faixa esperada. Divergência explicada é operação normal; divergência sem explicação é incidente.

Modern data stack, em uma frase

Conjunto de ferramentas gerenciadas e desacopladas — ingestão, armazenamento em nuvem, transformação em SQL, orquestração, catálogo e BI — montadas por integração em vez de por plataforma única.

Se quiser outro ângulo1 vídeo

Resumo curto dos princípios do Mesh. Assista já perguntando quais deles exigem mudança de organograma, porque é aí que a banca costuma cutucar.

Como cai na sabatina

“O saldo no core diverge do saldo no relatório. Qual é a fonte da verdade?”

Erros comuns

Descrever Lambda e Kappa como opções equivalentes. Lambda cobra caro em manter a mesma regra escrita duas vezes; Kappa cobra em reprocessamento de histórico pelo próprio stream. Sem citar esse custo, a resposta vira lista.
Tratar Lakehouse como marketing de Data Lake. O que muda é concreto: formato de tabela com transação, evolução de schema e time travel sobre armazenamento de objetos.
Dizer que Data Mesh é arquitetura técnica. Os quatro princípios são organizacionais antes de tudo; sem times de domínio com dono, o Mesh vira lake bagunçado com nome novo.
Confundir Source of Record com Source of Truth. SoR é onde o dado nasce; SoT é a visão consolidada e governada usada para decidir. Podem ser sistemas diferentes sem que ninguém esteja errado.
Responder que a fonte da verdade é sempre o core bancário. Para saldo em tempo real, sim; para o número do relatório regulatório de fechamento, a verdade é a visão consolidada e datada, não a tela do momento.
Propor Data Mesh para uma empresa com um time de dados de oito pessoas. Governança federada e plataforma self-serve exigem escala organizacional; abaixo dela, é overhead.

Flashcards

Card 1 de 14

0 certos · 0 a rever

Drill

SoR ou SoT?

Para cada afirmação, classifique o papel do sistema descrito.

1.O core bancário, que registra o lançamento no instante em que a transação de cartão é autorizada.
2.A tabela gold de posição consolidada de clientes, usada pelo relatório regulatório e pela diretoria.
3.O sistema de cadastro, onde o cliente informa o endereço no onboarding.
4.A visão unificada de cliente que resolve duplicidade entre cadastro, cartão e seguros e escolhe o endereço vigente.
5.O extrator do PIX, que grava na zona raw o payload cru recebido do SPI.

Drill

Qual arquitetura responde ao cenário?

Escolha a arquitetura mais adequada e prepare uma frase justificando o custo que você aceita.

1.Relatório regulatório mensal sobre dados estruturados, com modelagem estável há anos e exigência forte de rastreabilidade.
2.Guardar por sete anos o payload cru de PIX, log de app e áudio de call center, sem saber ainda que perguntas serão feitas.
3.Tabelas de transação que precisam de atualização corretiva, leitura concorrente por Spark e SQL, e reconstrução de um estado passado para auditoria.
4.Um conglomerado com áreas de cartão, seguros, crédito e câmbio, cada uma com time de engenharia próprio, e uma fila de meses no time central de dados.
5.Uma fintech com doze pessoas no total, sendo duas de dados, e um único banco transacional.

Quiz · 1 de 2

O que o Lakehouse acrescenta a um Data Lake?

Explique para um gerente

Explique para o diretor de operações, em um minuto, por que o número do relatório de saldo pode legitimamente diferir do número da tela do gerente, sem que nenhum dos dois esteja errado.

Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.

Prefiro falar em voz alta

00:00

Toque para gravar, ou responda em voz alta sem gravar

Perguntas de sabatina deste tema2

· O saldo no core diverge do saldo no relatório gerencial. Qual é a fonte da verdade?
· A diretoria leu sobre Data Mesh e quer adotar. Vocês têm quatro domínios grandes, um time central de dados com fila de três meses e nenhuma plataforma self-serve. O que você recomenda?

Responder no simulado

Para ir além5 artigos