Desmistificando o MySQL: Quando a Normalização Atrapalha Microserviços

Onde a Normalização Começa a Sabotar Microserviços

O problema não é o MySQL. O problema é achar que normalização extrema é virtude universal. Em microserviços, isso vira dívida técnica disfarçada de “boas práticas”.

O cenário clássico das trincheiras: times tentando dividir tabelas 3FN entre serviços diferentes, joins virando requisições remotas, latência explodindo e logs mostrando cascatas de timeouts dignos de filme de terror.

A verdade crua: quando você normaliza demais um domínio que já é distribuído, você transforma comunicação interna em gargalo de rede. E ninguém te conta isso na faculdade.

Normalização Inteligente: O Jeito Pragmático de Fazer MySQL Trabalhar a Seu Favor

A solução não é jogar normalização pela janela. É aplicar com critério. Em microserviços, o jogo muda: isolamento de dados vale mais do que pureza relacional.

Quer pragmatismo? Aqui vai:

• Normalização só até o nível em que cada microserviço controla seu próprio agregado.
• Nada de dividir tabelas entre serviços. Se precisa disso, seu boundary está errado.
• Consistência eventual é amiga, não inimiga.

Implementação de Sênior: Modelando um Domínio Sem Over‑Engineering

Exemplo prático com um microserviço de Orders que NÃO depende de joins remotos e NÃO vira refém de outro banco.

Modelo simplificado e propositalmente desnormalizado para refletir o agregado completo:

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  customer_id BIGINT NOT NULL,
  total DECIMAL(10,2) NOT NULL,
  status VARCHAR(30) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE order_items (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_id BIGINT NOT NULL,
  product_id BIGINT NOT NULL,
  product_name VARCHAR(255) NOT NULL,
  unit_price DECIMAL(10,2) NOT NULL,
  quantity INT NOT NULL,
  FOREIGN KEY (order_id) REFERENCES orders(id)
);

“Mas Rei, por que repetir product_name e unit_price?”

Porque esse microserviço não é catálogo. Ele precisa da fotografia do pedido no momento da compra, não dos dados atuais do produto. Isso é domínio, não é gambiarra.

Fluxo de consistência eventual via evento simplificado:

// Pseudocódigo de publicação de evento
publish("order.created", {
  orderId: id,
  total: total,
  items: orderItems
});

Assim, outro serviço pode reagir sem obrigar o Order Service a fazer chamadas remotas.

O Preço da Liberdade: Trade-offs da Normalização Controlada

Aqui é onde os adultos conversam. Não existe escolha sem custo:

• Desnormalizar exige disciplina. Se espalhar dado demais, vira bagunça. Faça apenas dentro do agregado.
• Consistência eventual não é para ansiosos. Se o negócio exige estado global atualizadíssimo, microserviços podem não ser o melhor caminho.
• Mais armazenamento. Sim, vai duplicar dados. E sim, é barato. O tempo do seu time não é.

Direto das Trincheiras

• Antes de normalizar, valide se o dado realmente pertence ao mesmo contexto de negócio.
• Se seu serviço precisa fazer join remoto para funcionar, seu design já quebrou.
• Quando um microserviço exige mais de três integrações síncronas para responder uma requisição, isso é cheiro de monólito distribuído.

Fontes Relacionadas

CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO,
Ciência da Computação | Graduação Unifor – Graduação

Obrigado por acompanhar essa reflexão até o fim!

Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog, onde descascamos outros hypes da nossa área.

Valeu e até a próxima! 😉