Mas existe um componente que sustenta absolutamente tudo.

O banco de dados.

Se removermos o frontend, o sistema continua existindo.

Se removermos a camada de IA, o sistema continua funcionando.

Mas se removermos o banco de dados:

Não existem produtos.

Não existem pedidos.

Não existem pagamentos.

Não existem conversas.

Não existe histórico.

Não existe negócio.

Por isso, entender arquitetura de dados é uma habilidade essencial para qualquer engenheiro de software.

Neste artigo você aprenderá:

• O papel do banco de dados;
• Como modelar entidades de negócio;
• Como criar relacionamentos;
• Como garantir consistência;
• Como utilizar PostgreSQL em sistemas modernos;
• Como integrar IA com pgvector e RAG;
• Como pensar como um arquiteto de dados.

O Papel do Banco de Dados

O banco de dados é a memória permanente de um sistema.

Tudo aquilo que precisa continuar existindo após uma requisição precisa ser armazenado.

Exemplos:

Produtos

Pedidos

Pagamentos

Clientes

Conversas

Documentos

Imagine que um cliente feche o navegador logo após realizar uma compra.

O pedido continua existindo.

Por quê?

Porque foi persistido.

O banco é responsável por:

• armazenar;
• consultar;
• atualizar;
• garantir consistência.

O banco de dados é a memória permanente do negócio.

Modelando o Domínio

Antes de criar tabelas, precisamos entender o negócio.

A primeira pergunta é:

O que precisa existir no sistema?

Em um e-commerce moderno podemos identificar:

Produto

Carrinho

Pedido

Pagamento

Conversa

Mensagem

Documento

Esses elementos são chamados de entidades.

O Que é uma Entidade?

Uma entidade representa algo importante para o negócio.

Exemplos:

• Produto
• Pedido
• Pagamento
• Conversa

Uma regra importante:

"

Modelamos conceitos do negócio. Não modelamos telas.

Errado:

TelaCheckout

Correto:

Pedido

Produto: A Entidade Central

Em um e-commerce, praticamente tudo gira em torno do produto.

Uma estrutura simples poderia conter:

id
name
slug
description
price
stock_quantity
is_active
created_at
updated_at

O campo slug normalmente é utilizado em URLs amigáveis:

lustre-industrial-preto

O produto se relaciona diretamente com:

Carrinho

Pedido

Por isso costuma ser uma das entidades mais importantes do domínio.

Carrinho de Compras

O carrinho representa uma intenção de compra.

Uma boa modelagem separa:

Cart

Cart Item

O carrinho representa a sessão.

Os itens representam os produtos adicionados.

Exemplo:

Cart
↓
Cart Items
↓
Product

Essa separação permite:

• múltiplos produtos;
• controle de quantidade;
• histórico de preços.

Uma prática importante é armazenar o preço do produto no momento em que ele foi adicionado ao carrinho.

Assim futuras alterações não afetam a experiência do cliente.

Pedidos e Pagamentos Não São a Mesma Coisa

Um erro comum em sistemas iniciantes é misturar pedido e pagamento.

Mas são conceitos diferentes.

Exemplo:

Pedido criado
↓
Pagamento falhou

O pedido continua existindo.

Portanto precisamos de entidades separadas.

Order
↓
Payment

O pedido representa a intenção de compra.

O pagamento representa um evento financeiro.

Essa separação melhora:

• auditoria;
• rastreabilidade;
• consistência.

Modelando Conversas

Sistemas modernos frequentemente possuem atendimento integrado.

Para isso normalmente utilizamos duas entidades:

Conversation

Message

A conversa representa uma sessão.

A mensagem representa uma interação.

Fluxo:

Conversation
↓
Messages

Essa estrutura permite:

• histórico completo;
• integração com IA;
• transferência para atendimento humano.

Base de Conhecimento para IA

Aplicações modernas com IA precisam armazenar conhecimento.

Exemplos:

Política de Troca

FAQ

Garantias

Documentação

Procedimentos

Uma boa prática é separar:

Document

Chunk

Por quê?

Porque documentos grandes não funcionam bem em sistemas RAG.

Ao dividir em pequenos trechos, conseguimos recuperar apenas o conteúdo relevante.

Fluxo:

Documento
↓
Chunks
↓
Embeddings
↓
Busca Vetorial

O Que é pgvector?

Tradicionalmente o PostgreSQL era utilizado apenas para dados relacionais.

Hoje podemos transformá-lo também em uma plataforma de busca semântica.

Isso é possível utilizando:

pgvector

Com ele armazenamos:

Texto

+

Embedding

Exemplo:

Política de Troca

↓

[0.21, -0.77, 0.44, ...]

Quando o usuário faz uma pergunta:

Posso devolver um produto?

O sistema procura os vetores mais semelhantes.

Resultado:

Trechos relevantes encontrados

Essa abordagem é a base de sistemas RAG modernos.

Índices e Performance

Conforme o sistema cresce, as consultas ficam mais lentas.

A solução é utilizar índices.

Exemplo:

CREATE INDEX idx_products_slug
ON products(slug);

Outros campos frequentemente indexados:

status

product_id

order_id

conversation_id

Sem índices, até bons bancos de dados podem se tornar lentos.

Consistência e Transações

Uma das maiores vantagens do PostgreSQL é sua capacidade de manter consistência.

Imagine:

Pagamento aprovado

Precisamos atualizar:

Payment

e

Order

Essas operações devem acontecer juntas.

Para isso utilizamos transações.

BEGIN;

UPDATE payments ...

UPDATE orders ...

COMMIT;

Se algo falhar:

ROLLBACK;

Tudo volta ao estado anterior.

Isso evita inconsistências críticas.

Observabilidade da Camada de Dados

Bancos de dados também precisam ser monitorados.

Algumas métricas importantes:

• consultas lentas;
• conexões abertas;
• uso de CPU;
• uso de memória;
• crescimento do banco;
• espaço em disco.

Uma boa observabilidade permite identificar problemas antes que impactem os usuários.

Como Fica o Modelo da Lumina Store

Ao final, nosso domínio é composto por:

Products

Carts

Cart Items

Orders

Payments

Conversations

Messages

Documents

Chunks

Cada entidade possui uma responsabilidade específica.

Juntas, elas sustentam toda a operação do sistema.

Conclusão

Arquitetura de dados vai muito além de criar tabelas.

Ela envolve compreender o negócio, modelar corretamente os conceitos e garantir que os dados permaneçam consistentes ao longo do tempo.

Ao longo deste artigo vimos:

• O papel do banco de dados;
• Como modelar entidades;
• Como criar relacionamentos;
• Como utilizar PostgreSQL;
• Como suportar IA com pgvector;
• Como garantir consistência com transações;
• Como monitorar a camada de dados.

A principal lição é simples:

"

Bancos de dados não armazenam apenas informações. Eles armazenam o estado do negócio.

E compreender isso é um dos primeiros passos para pensar como um arquiteto de software.