Pular para o conteúdo

apps/architecture/data-mesh

049 · Arquiteturas de Alto Nível (Macro-Architecture) · ≈ 6 min de estudo

Data Mesh

Em vez de um data lake central que lê o banco de todos os times, cada domínio é dono do próprio dado e o publica como data product: uma rota versionada com contrato de schema, dono e SLA de frescor. Quem precisa cruzar domínios consome os contratos — nunca o banco alheio. O que separa Data Mesh de “vários bancos” é o contrato.

passos
6
arquivos
8
teste
1
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
Baixar cartão

Cenário

Banco digital com os times de Risco, Pagamentos e Crédito, cada um com seu banco. O atendimento quer a visão 360 do cliente — score, movimentação e limite disponível — sem pedir acesso aos bancos dos outros times e sem quebrar quando um time muda sua tabela interna.

Planta

Fluxo
7/7
Domínio de risco - team-riskDomínio de pagamentos - team-paymentsDomínio de crédito - team-creditrisk_dbv1/risk-scores e/data-contractpayments_dbv1/payment-summarye /data-contractcredit_dbv1/credit-positione /data-contractVisão cliente 360lê contrato, confereversão, consomenunca
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Domínios publicam dados como produto.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    Cada domínio tem banco próprio; só o serviço dele conecta

  2. 02

    O contrato é um schema TypeBoxValida a resposta da rota e é publicado em /data-contract como JSON Schema, com versão, dono e freshnessSla

  3. 03

    O contrato é uma visão estável — used_cents fica dentro do crédito; o produto publica availableCents

  4. 04

    A rota carrega a versão maior (/v1/...); mudança incompatível vira /v2 servida junto com a /v1 na migração

  5. 05

    O consumidor lê o contrato, recusa versão maior diferente da que conhece e payload sem campo obrigatório

  6. 06

    A visão 360 junta os três produtos em paralelo, sem JOIN e sem conexão a banco alheio

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • Sem gargalo de um time central de BI

  • Times mudam o schema interno livremente

  • Consumidor sabe o frescor de cada dado

Custos

  • Consulta entre domínios exige várias chamadas

  • Contrato vira API pública: mudança incompatível é breaking change

  • N bancos e N serviços para operar

apps/architecture/data-mesh

8 arquivos

./

  • docker-compose.ymlinfraUm PostgreSQL por domínio: 5432, 5433, 5434

sql/01_risk.sql / 01_payments.sql /

  • 01_credit.sqlschemaTabelas internas de cada domínio

src/

  • contract_product.tsFormato do contrato, publicação e checagem no consumidor
  • consumer_customer360.tsVisão 360 montada só por contratos
  • config_mesh.tsVariáveis de ambiente validadas no boot
  • demo.tsdemoContratos, visão 360 e recusa de versão incompatível
  • consumer_customer360.test.tstestePosse do dado, contrato igual ao payload, cliente novo e governança contra três bancos reais

src/product_risk.ts / product_payments.ts /

  • product_credit.tsData product de cada domínio

Executar · com Docker

  1. docker compose up -d --wait# sobe PostgreSQL
  2. bun install# dependências
  3. bun run demo# roda o cenário
  4. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Por que se relacionam

Teste rápido

Qual destes combina com Data Mesh?

Próximo projeto · Comunicação & MensageriaAsync Messaging
Esc

↑ ↓ navegarEnter abrir191 resultados