Pular para o conteúdo
thiagoetipadrões

Contatos

apps/data-patterns/shared-database

083 · Dados & Persistência · ≈ 6 min de estudo

Shared Database (anti-padrão)

Vários serviços usam o mesmo banco, o mesmo schema e o mesmo login: qualquer um lê e escreve qualquer tabela. Começa simples — JOIN direto entre domínios e uma transação que cobre tudo — e termina com times que não conseguem mudar as próprias tabelas sem quebrar os outros. É o contraponto de database-per-service. A instância compartilhada só é aceitável com um escritor por tabela, sem chave estrangeira entre domínios e ninguém lendo a tabela do outro — e aqui o próprio banco impõe isso.

passos
6
arquivos
6
teste
1
tecnologias
4
Infraestrutura realTypeScriptBunPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Banco digital com os serviços de Contas e de Lançamentos apontando para o mesmo banco. Lançamentos, ao registrar um crédito, atualiza direto o saldo na tabela de Contas. Contas lista as contas com o nome do titular fazendo JOIN na tabela de Clientes. Um dia o time de Clientes renomeia name para full_name — e Contas cai, sem ninguém ter mexido no código dele.

Planta

Fluxo
7/7
Anti-padrão - um schema, um loginForma aceitável - schema e login por serviçoServiço de ContascustomersaccountsServiço de Lançamentosledger_entrieslogin accounts_serviceaccounts_domain.accountslogin ledger_serviceledger_domain.ledger_entriesJOIN customersUPDATE saldo deoutro domíniopermission denied
7

7 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Banco compartilhado acopla os serviços.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

GRANT+1
permission denied+1
  1. 01

    No anti-padrão os dois serviços conectam com o mesmo login no mesmo schema

  2. 02

    Lançamentos grava o lançamento e o saldo de Contas na mesma transação — a única vantagem real do modelo

  3. 03

    Contas depende de customers.name sem contrato: a renomeação do outro time quebra a consulta

  4. 04

    Na forma aceitável cada serviço tem schema e login próprios; GRANT só no próprio schema

  5. 05

    O login de Lançamentos grava o próprio lançamento e recebe permission denied ao tentar ler ou escrever o saldo de Contas

  6. 06

    Saldo passa a ser responsabilidade de Contas, alcançado por API ou evento

Trade-offs

O que se ganha, o que se paga

3 vantagenscada ganho tem um preço3 custos

Vantagens

  • JOIN e transação entre domínios

  • Nenhuma latência de rede entre serviços

  • Setup inicial trivial

Custos

  • Mudar uma coluna quebra outros serviços

  • Deploy e escala não são independentes

  • Sem fronteira: qualquer serviço altera qualquer tabela

apps/data-patterns/shared-database

6 arquivos

sql/

  • 01_schema.sqlschemaSchema compartilhado do anti-padrão, schemas por domínio e os logins com seus GRANT

src/

  • service_accounts.tsAbertura de conta e listagem com JOIN entre domínios
  • service_ledger.tsLançamento cruzando domínios e lançamento restrito ao próprio schema
  • demo.tsdemoAcoplamento, quebra pela renomeação e recusa pelo banco
  • service_ledger.test.tstesteTransação entre domínios, quebra por renomeação e grants contra PostgreSQL real

src/config_shared.ts / src/

  • pool_shared.tsAmbiente validado, pool e transactionExecute

Executar · com Docker

  1. ./docker.sh up# 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

Relações

Onde ele se encaixa

Mapa
  1. Shared Database
  • Combina com2
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Shared Database?

Próximo projeto · Dados & PersistênciaRead Replicas
Esc

↑ ↓ navegarEnter abrir191 resultados