DEV Community: Flávio Luiz

Monitoring na prática: olhando além do “o sistema está no ar”

Flávio Luiz — Fri, 03 Oct 2025 02:28:17 +0000

Quando falamos de monitoramento, não basta saber se o site responde. É preciso entender como ele responde, para quem, em que condições e com que riscos.

Vamos quebrar isso em camadas, com exemplos de um marketplace em produção:

🔍 Health Monitoring

Checar se os serviços estão vivos.
➡Exemplo prático: rodar health checks automáticos a cada 30 segundos no serviço de pagamentos. Se ele parar de responder, o load balancer remove a instância para não impactar novos clientes.

🌐 Availability Monitoring

É diferente de “estar no ar”: significa estar realmente acessível para o usuário.
➡ Exemplo prático: o checkout está online, mas 20% dos usuários do Nordeste não conseguem acessá-lo por problemas de rota em um provedor de internet local. Um monitor de disponibilidade global detecta a falha de rede e aciona fallback para outro provedor de CDN.

⚡ Performance Monitoring

Não é só uptime: é tempo de resposta e consumo de recursos.
➡ Exemplo prático: durante a Black Friday, o endpoint /search começa a responder em 4 segundos em vez de 500ms. O time recebe alerta no DataDog, analisa traces no OpenTelemetry e descobre que a query no banco perdeu o índice após um deploy.

🔒 Security Monitoring

Monitorar não só ataques externos, mas também anomalias internas.
➡ Exemplo prático: um padrão de chamadas para /login com milhares de tentativas por minuto indica um ataque de credential stuffing. O monitor de segurança dispara um alerta e aciona automaticamente bloqueio via WAF e reCAPTCHA.

📊 Usage Monitoring

Mede comportamento real do usuário e impacto no negócio.
➡ Exemplo prático: métricas mostram que 60% dos usuários abandonam o carrinho ao adicionar mais de 5 itens. Com isso, o time percebe que a UX da tela de resumo está confusa e ajusta o fluxo.

🛠️ Instrumentation

Colocar métricas e logs no código de forma planejada.
➡ Exemplo prático: o serviço de pedidos emite métricas para cada evento: pedido_criado, pedido_pago, pedido_cancelado. Isso permite construir funis no dashboard e entender onde os usuários travam.

🚨 Visualization & Alerts

É a forma como o time consome os dados de monitoramento.
➡ Exemplo prático: dashboards no Grafana mostram latência, throughput e taxa de erros em tempo real. Alertas no Slack/Teams são configurados com thresholds dinâmicos (ex.: erro > 2% por 5 minutos) para evitar falsos positivos.

Conclusão

Monitoramento é como cuidar da saúde de uma pessoa: não basta medir a pressão, é preciso olhar coração, respiração, comportamento e sinais de alerta.
No mundo dos sistemas, é o que garante confiança, escalabilidade e segurança.

👉 E aí: no seu time vocês já têm monitoramento distribuído (com traces, métricas e logs) ou ainda dependem de “alguém avisar que deu erro”?

Como a comunicação na Web realmente funciona (com exemplos práticos e simples)

Flávio Luiz — Fri, 03 Oct 2025 02:01:35 +0000

Quando você entra em um site de marketplace para comprar um tênis, muita coisa acontece por trás da tela. Existe uma verdadeira “conversa” entre computadores e servidores para que a página carregue, o preço apareça e o pedido seja processado. Essa conversa é a comunicação na web.

Quero explicar de forma simples alguns conceitos que usamos no dia a dia do desenvolvimento de software: HTTP, TCP, UDP, RPC, gRPC, REST e GraphQL.

TCP e UDP: o alicerce da conversa

Pense que a internet é como uma estrada. Para mandar informações, precisamos de regras de trânsito. É aqui que entram o TCP e o UDP.

TCP (Transmission Control Protocol):
É como enviar um produto por correio com aviso de recebimento. O servidor confirma cada pacote de dados que chegou. Isso garante segurança e ordem, mas pode ser mais lento.
→ Exemplo no marketplace: quando você confirma a compra, não dá pra perder nenhuma informação do cartão de crédito. O TCP garante que tudo chegue certinho.

UDP (User Datagram Protocol):
É como mandar uma mensagem de voz no WhatsApp: se perder um pedacinho, segue o baile. Ele é mais rápido porque não confirma cada entrega.
→ Exemplo no marketplace: se houver um sistema de recomendação em tempo real ou uma transmissão ao vivo de um vendedor, o UDP pode ser usado. Melhor receber algo rápido do que perfeito.

RPC e gRPC: pedindo favores

RPC (Remote Procedure Call) é como ligar para um amigo e pedir:
“Cara, pode rodar aquela função pra mim aí no seu computador e me passar o resultado?”.
No mundo web, RPC é isso: chamar métodos em outro sistema como se fossem locais.

gRPC (Google Remote Procedure Call) é uma versão moderna desse conceito. Ele é super eficiente, usa HTTP/2 e transmite dados em binário (Protobuf), em vez de texto.
→ Exemplo no marketplace: quando o app precisa verificar em milissegundos se um produto ainda está no estoque, gRPC é ótimo porque é rápido e econômico.

REST: o clássico que todo mundo usa

O REST é um estilo de comunicação baseado no HTTP. Ele trata cada recurso (produto, pedido, cliente) como uma URL.

GET /produtos/123 → Buscar o produto de id 123

POST /pedidos → Criar um novo pedido

GraphQL: perguntando só o que precisa

O GraphQL nasceu para resolver um problema do REST: o excesso ou falta de dados.
Imagine que a página do tênis precisa do nome, preço e cor.

No REST, você provavelmente recebe muito mais informação do que precisa (descrição, avaliações, imagens etc).

No GraphQL, você faz uma única query pedindo só o que quer:

{
  produto(id: "123") {
    nome
    preco
    cor
  }
}

Conclusão

No fundo, todos esses protocolos e estilos são diferentes formas de resolver o mesmo problema: como dois sistemas trocam informações de maneira eficiente e confiável.

TCP/UDP → base da comunicação

HTTP → idioma padrão da web

RPC/gRPC → chamadas rápidas e diretas

REST → clássico e simples

GraphQL → sob medida, sem desperdício

[BD] História 4: Lory e o Uso de Cache com Go

Flávio Luiz — Thu, 28 Nov 2024 01:13:49 +0000

O Desafio da Performance no E-commerce
Lory, uma programadora dedicada, teve mais uma ideia para melhorar a performance do ecommerce, fazer o uso de cache. Tabelas como Order, Customer, Invoice e Product acumularam milhões de registros, e as consultas começaram a sofrer com lentidão. Lory sabia que precisava agir para otimizar o desempenho e garantir uma experiência fluida para os usuários.

A Solução com Cache
Lory decidiu implementar um sistema de cache usando Redis, uma ferramenta popular que armazena dados em memória para respostas rápidas. Em vez de consultar o banco de dados diretamente, os resultados frequentemente acessados seriam armazenados em cache.

Implementação em Go

Lory usou a biblioteca go-redis para interagir com o Redis.
Configuração do Redis: Primeiro, ela configurou o cliente Redis.

import (
    "context"
    "github.com/redis/go-redis/v9"
)
var ctx = context.Background()
func newRedisClient() *redis.Client {
    return redis.NewClient(&redis.Options{
        Addr: "localhost:6379",
    })
}

Consulta com Cache: Depois, ela implementou uma função para buscar pedidos de um cliente. Se os dados estivessem em cache, eram retornados rapidamente. Caso contrário, a consulta seria feita no banco, e os dados armazenados em cache.

type Order struct {
    OrderID    int
    CustomerID int
    OrderDate  string
    Amount     float64
}
func getOrdersByCustomer(redisClient *redis.Client, customerId int) ([]Order, error) {
    cacheKey := fmt.Sprintf("orders:%d", customerId)

    // Tenta buscar no cache
    cachedOrders, err := redisClient.Get(ctx, cacheKey).Result()
    if err == nil {
        // Deserializa os pedidos do cache
        var orders []Order
        json.Unmarshal([]byte(cachedOrders), &orders)
        return orders, nil
    }

    // Se não estiver no cache, consulta no banco de dados (simulação)
    orders := []Order{
        {OrderID: 1, CustomerID: customerId, OrderDate: "2024-11-01", Amount: 150.00},
    }

    // Salva os resultados no cache
    data, _ := json.Marshal(orders)
    redisClient.Set(ctx, cacheKey, data, 3600*time.Second)
    return orders, nil
}

Benefícios e Limitações do Cache
Benefícios:

Resposta Rápida: Dados em cache são retornados em milissegundos.
Redução de Carga no Banco: Menos consultas diretas ao banco liberam recursos para outras operações.
Escalabilidade: Suporta mais usuários simultaneamente.

Limitações:

Dados Desatualizados: Alterações no banco podem não ser refletidas imediatamente no cache.
Consumo de Memória: Armazenar grandes volumes de dados no Redis pode sobrecarregar os recursos.
Complexidade de Implementação: Exige planejamento para garantir que o cache seja sincronizado corretamente.

Lições Aprendidas

Cache Não É a Solução Definitiva: Deve complementar, não substituir, otimizações no banco.
Garantir dados atualizados: Criar estratégias para garantir que os dados no cache estejam sempre atualizados conforme as regras de negócio.
Monitoramento Contínuo: Ferramentas como Prometheus ajudaram Lory a identificar gargalos.

Conclusão
A jornada de Lory mostra que melhorar a performance no banco de dados é um processo contínuo. Com cache, views, particionamento e processamento assíncrono, ela transformou o sistema em uma plataforma escalável e eficiente, pronta para crescer junto com o negócio.

[BD] História 3: Lory e a Desnormalização no Sistema de E-commerce

Flávio Luiz — Thu, 28 Nov 2024 00:18:05 +0000

Nessa história, vamos abordar temas de Desnormalização de um banco de dados

Lory continuou com problemas de performance no banco de dados, dessa vez ela foi ousada e resolveu fazer uma desnormalização de algumas tabelas para melhorar a performance. Inicialmente, a aplicação usava um modelo normalizado com tabelas para Ordem, Pedido, Cliente e NotaFiscal.

Consultas lentas em horários de pico.
Relatórios demorados, afetando as decisões estratégicas.
Sobrecarregamento do banco de dados, prejudicando integrações como o ERP.

A Desnormalização como uma possível Solução
Lory percebeu que muitas das consultas mais lentas envolviam joins complexos entre tabelas grandes. Por exemplo, um relatório básico de pedidos por cliente demorava vários minutos:

SELECT 
    c.ClienteID,
    c.Nome AS Cliente,
    COUNT(p.PedidoID) AS TotalPedidos,
    SUM(o.Quantidade * o.Preco) AS ValorTotal,
    MAX(nf.DataEmissao) AS UltimaNotaFiscal
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
GROUP BY c.ClienteID, c.Nome;

Lory decidiu desnormalizar os dados, criando uma tabela que consolidava as informações frequentemente consultadas:

CREATE TABLE ResumoPedidos (
    ClienteID INT,
    Nome VARCHAR(100),
    TotalPedidos INT,
    ValorTotal DECIMAL(18, 2),
    UltimaNotaFiscal DATE
);

E preencheu os dados com uma query agendada periodicamente, um cron que rodava 1x por dia e executava a seguinte query em Postgre:

INSERT INTO ResumoPedidos
SELECT 
    c.ClienteID,
    c.Nome,
    COUNT(p.PedidoID),
    SUM(o.Quantidade * o.Preco),
    MAX(nf.DataEmissao)
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
WHERE p.DtCriacao = CURRENT_DATE - INTERVAL '1 day'
GROUP BY c.ClienteID, c.Nome;

Obs. Os requisitos permitiam esse cenário, mas poderia ser em qualquer período, isso pode variar por necessidade de negócio.

Resultados da Desnormalização

Consultas mais rápidas: Dados consolidados reduziram o tempo de execução de queries de minutos para segundos.
Relatórios instantâneos: Relatórios complexos tornaram-se viáveis em tempo real.
Integração facilitada: O ERP agora consumia dados da tabela desnormalizada, diminuindo sua dependência de joins pesados.

Limitações da Desnormalização
Apesar das melhorias, Lory enfrentou alguns desafios:

Manutenção Complexa: Alterar os dados exigia sincronizar tabelas normalizadas e desnormalizadas.
Armazenamento Adicional: Dados duplicados aumentaram o consumo de espaço.
Dados Desatualizados: Se o processo de atualização falhasse, os relatórios poderiam apresentar informações inconsistentes.

Aprendizados
Quando a Desnormalização é Necessária

A desnormalização é útil quando o sistema enfrenta gargalos de performance devido a joins complexos em tabelas grandes.
É indicada em cenários onde a velocidade de leitura é mais importante que a consistência perfeita dos dados.
Consultas complexas envolvendo várias tabelas (como JOIN e agregações) podem ser otimizadas armazenando dados consolidados em tabelas desnormalizadas.
O armazenamento de dados pré-calculados reduz o tempo de execução de queries frequentes, tornando o sistema mais responsivo.

[BD] História 2: Lory e a Criação de Views no Sistema de E-commerce

Flávio Luiz — Tue, 26 Nov 2024 13:16:10 +0000

Nessa história, vamos abordar temas de Views de um banco de dados

O Crescimento do Sistema
Depois de solucionar os problemas de performance com indexação, Lory viu o e-commerce prosperar. Porém, como todo sistema em crescimento, novos desafios surgiram. Os lojistas começaram a solicitar relatórios mais detalhados, como pedidos consolidados por cliente, produtos mais vendidos e informações fiscais. Além disso, a integração com o ERP da empresa tornou-se essencial para automatizar processos.

Essas novas demandas sobrecarregaram o sistema. Consultas complexas que uniam tabelas como Ordem, Pedido, Cliente e NotaFiscal começaram a impactar a performance. Relatórios que deveriam ser gerados em minutos passaram a levar horas, afetando o atendimento aos lojistas.

O Problema de Performance
Lory percebeu que o gargalo estava nas consultas que uniam grandes tabelas. Uma das queries problemáticas era:

SELECT 
    c.ClienteID,
    c.Nome AS Cliente,
    COUNT(p.PedidoID) AS TotalPedidos,
    SUM(o.Quantidade * o.Preco) AS ValorTotal,
    MAX(nf.DataEmissao) AS UltimaNotaFiscal
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
GROUP BY c.ClienteID, c.Nome;

Essa consulta fazia leituras demoradas nas tabelas e consumia muitos recursos do banco de dados, especialmente em horários de pico.

A Solução com Views
Lory encontrou a solução nas views do banco de dados. Ela percebeu que poderia criar uma estrutura pré-processada para consolidar os dados frequentemente utilizados, reduzindo o tempo de execução das consultas.

A Criação da View
Lory criou uma view para consolidar as informações mais usadas pelos relatórios e pelo ERP:

CREATE VIEW vw_ResumoPedidos AS
SELECT 
    c.ClienteID,
    c.Nome AS Cliente,
    COUNT(p.PedidoID) AS TotalPedidos,
    SUM(o.Quantidade * o.Preco) AS ValorTotal,
    MAX(nf.DataEmissao) AS UltimaNotaFiscal
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
GROUP BY c.ClienteID, c.Nome;

Agora, em vez de executar a consulta diretamente nas tabelas, o sistema poderia acessar a view:

SELECT * FROM vw_ResumoPedidos WHERE ClienteID = 12345;

O Resultado
Com a criação da view:

Consultas complexas que antes levavam minutos agora eram respondidas em segundos.
Relatórios passaram a ser gerados mais rapidamente.
A integração com o ERP foi simplificada, pois o sistema podia acessar dados consolidados diretamente na view.

As Limitações e os Novos Desafios
Apesar do sucesso inicial, Lory percebeu algumas limitações no uso de views:

Problemas Identificados

Views Não Indexadas: Consultas em views sem índices eram lentas em tabelas muito grandes.
Manutenção Difícil: Alterações nas tabelas base exigiam que Lory ajustasse a lógica da view.
Uso de Recursos: Views complexas consumiam muitos recursos do banco de dados em horários de alta demanda.

O Impacto na Integração com o ERP
Ao integrar o sistema com o ERP, o volume de dados acessado aumentou ainda mais. O ERP dependia da view para consolidar informações, e em horários de pico, as consultas começaram a afetar novamente o desempenho geral do sistema.

A Solução para Escalabilidade
Lory sabia que precisava otimizar ainda mais o sistema. Ela implementou as seguintes melhorias:

1. Views Materializadas
Para evitar que a view recalculasse os dados a cada consulta, Lory criou uma view materializada:

CREATE MATERIALIZED VIEW mv_ResumoPedidos AS
SELECT 
    c.ClienteID,
    c.Nome AS Cliente,
    COUNT(p.PedidoID) AS TotalPedidos,
    SUM(o.Quantidade * o.Preco) AS ValorTotal,
    MAX(nf.DataEmissao) AS UltimaNotaFiscal
FROM Cliente c
JOIN Pedido p ON c.ClienteID = p.ClienteID
JOIN Ordem o ON p.PedidoID = o.PedidoID
JOIN NotaFiscal nf ON p.PedidoID = nf.PedidoID
GROUP BY c.ClienteID, c.Nome;

A view materializada armazenava os dados pré-calculados, reduzindo o custo das consultas subsequentes.

2. Atualizações Periódicas
Para manter os dados da view atualizados, ela configurou um processo periódico:

REFRESH MATERIALIZED VIEW mv_ResumoPedidos;

Lições Aprendidas

Views Simplificam Consultas: Consolidar dados com views reduz o tempo de execução de consultas complexas.
Manutenção Regular é Essencial: Views materializadas precisam de atualizações periódicas para garantir dados consistentes.
Equilíbrio entre Simplicidade e Performance: Soluções como views materializadas e particionamento exigem planejamento para evitar complexidade excessiva.

Com essas melhorias, o sistema de Lory tornou-se mais escalável e capaz de suportar o crescimento do e-commerce e a integração com o ERP. Os lojistas estavam felizes, e Lory continuava a aprender e aplicar novas estratégias para enfrentar desafios futuros.

Referencias
https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html
https://www.postgresql.org/docs/17/sql-creatematerializedview.html
https://www.postgresql.org/docs/17/sql-createview.html

[BD] História 1: A Jornada de Lory e a Indexação

Flávio Luiz — Mon, 25 Nov 2024 17:31:08 +0000

Nessa história, vamos abordar temas de indexação de um banco de dados

Capítulo 1: O Início do Sistema de E-commerce
Lory, uma desenvolvedora entusiasta e cheia de ideias, começou a trabalhar em uma startup que tinha um e-commerce para atender pequenas lojas locais. Ela criou uma tabela simples com nome de Order para armazenar os pedidos, contendo colunas como OrderID, CustomerID, OrderDate e Amount. O sistema era rápido, pois os primeiros clientes tinham poucos pedidos.

No entanto, conforme o sucesso do sistema cresceu, mais lojas aderiram à plataforma e o volume de dados aumentou exponencialmente. Em poucos meses, a tabela Order acumulou milhões de registros. Lory percebeu o problema quando um lojista reclamou que ao tentar visualizar os pedidos de um cliente específico, a página levava minutos para carregar.

O Desafio da Performance
Lory investigou o problema e percebeu que a consulta abaixo, usada para filtrar os pedidos por cliente, estava realizando um table scan, varrendo linha por linha da tabela:

SELECT * FROM Order WHERE CustomerID = 12345;

Essa query era ineficiente, especialmente com milhões de registros. Ela sabia que precisava resolver o problema rapidamente, ou os lojistas começariam a abandonar sua plataforma.

A Solução com Indexação
Lory começou a estudar sobre técnicas de otimização de banco de dados e descobriu a indexação. Ela aprendeu que, ao criar um índice na coluna CustomerID, o banco de dados seria capaz de localizar os registros rapidamente, sem precisar examinar cada linha. Ela implementou o seguinte comando:

CREATE INDEX idx_customer_id ON Order(CustomerID);

O impacto foi imediato. Consultas que antes levavam minutos passaram a ser concluídas em segundos. Lory ficou satisfeita ao ver os lojistas elogiando a rapidez do sistema.

O Retorno do Desempenho Lento
Porém, nem tudo eram flores. Com o aumento do número de pedidos diários, Lory começou a notar uma lentidão nas operações de inserção de novos pedidos. Ela percebeu que, ao adicionar um novo pedido na tabela Order, o banco de dados também precisava atualizar o índice criado, o que estava consumindo tempo adicional.

Ela testou a seguinte query de inserção e confirmou a lentidão:

INSERT INTO Order (CustomerID, OrderDate, Amount) VALUES (12345, '2024-11-01', 150.00);

Lory entendeu que a indexação, embora eficiente para consultas, tinha um impacto negativo nas operações de escrita. Além disso, ela começou a notar que os índices criados estavam aumentando significativamente o espaço usado pelo banco de dados.

Capítulo 1.2: Lory e o Desafio das Inserções Lentas
Lory estava satisfeita com a solução de indexação que acelerou as consultas no sistema de e-commerce. As reclamações dos lojistas cessaram, e o sistema voltou a funcionar de forma eficiente. Porém, como todo bom desenvolvedor sabe, novos problemas sempre surgem quando um sistema cresce.

A Chegada do Problema
Meses depois, Lory notou que as operações de inserção começaram a ficar lentas. O volume de vendas no sistema havia disparado, com dezenas de pedidos sendo registrados a cada segundo. Os lojistas, empolgados com o crescimento de seus negócios, começaram a relatar que novos pedidos levavam mais tempo que o previsto, aumentando a desistência dos consumidores no site.

Lory investigou e percebeu que a lentidão estava diretamente relacionada aos índices que ela havia criado. A cada novo pedido inserido na tabela Order, o banco de dados precisava atualizar os índices associados, como o de CustomerID. Isso estava causando um impacto significativo na performance das operações de escrita.

Lory Buscou Algumas Soluções
Determinada a resolver o problema, Lory decidiu fazer uma pausa e pensar estrategicamente. Ela sabia que remover os índices não era uma opção, pois isso traria de volta o problema das consultas lentas. Então, ela começou a explorar alternativas para otimizar as inserções.

A Solução: Inserts Assíncronos
Lory começou a planejar uma solução mais robusta. Ela adicionou filas para gerenciar as operações de inserção.

Implementação de Filas: Lory configurou uma fila de mensagens com RabbitMQ. Cada novo pedido era enviado para a fila e era processado por um serviço de inserção dedicado.
Inserção Assíncrona: O serviço inseria os dados no banco de dados em segundo plano, mantendo os índices atualizados sem impactar diretamente a experiência dos lojistas.

Com isso, o sistema ficou preparado para lidar com picos de vendas sem sobrecarregar o banco de dados.

Lory Aprende Sobre Particionamento
Mesmo com as otimizações, a tabela Order continuava crescendo. Lory começou a implementar o particionamento de tabelas para dividir os dados em blocos menores por ano. Assim, os índices de cada partição eram menores e mais rápidos de atualizar. Ela particionou a tabela Order com base no campo OrderDate:

CREATE TABLE Order_2024 (...);
CREATE TABLE Order_2025 (...);

A Vitória
Graças às otimizações, o sistema de Lory continuou a crescer, suportando milhares de pedidos por minuto. Ela aprendeu que a indexação é essencial, mas o equilíbrio entre leitura e escrita é fundamental para o sucesso de um sistema em grande escala.

Lory tornou-se uma desenvolvedora mais experiente, entendendo que resolver problemas de performance é como ajustar uma máquina em constante movimento. E assim, o e-commerce prosperou, com seus lojistas cada vez mais satisfeitos.

Lições Aprendidas

Indexação é Fundamental, Mas Exige Planejamento
- A indexação acelera consultas ao organizar dados para buscas eficientes, mas pode impactar operações de escrita. É essencial balancear performance de leitura e escrita.
Monitoramento Contínuo é Essencial
- Sistemas em crescimento apresentam novos desafios. Monitorar consultas e analisar o uso de índices regularmente ajuda a identificar gargalos antes que eles se tornem problemas críticos.
Assincronismo para Melhor Escalabilidade
- A implementação de filas com RabbitMQ e inserções assíncronas desacoplou a escrita da lógica principal do sistema, permitindo lidar com picos de vendas sem afetar a experiência do usuário.
Particionamento de Dados Aumenta a Eficiência
- Dividir tabelas grandes em partições menores por ano, ajudou a manter os índices mais leves e rápidos, reduzindo o impacto tanto na leitura quanto na escrita.
O Equilíbrio é a Chave
- Nem sempre a solução para um problema será universal. Lory entendeu que a performance exige ajustes contínuos, considerando as demandas específicas de leitura e escrita.
Planejamento Previne Problemas Futuros
- Estratégias como índices e o uso de filas prepararam o sistema de Lory para crescer sem comprometer a performance.

7.Aprendizado e Adaptação Constantes

Lory mostrou que ser uma boa desenvolvedora não é apenas implementar soluções, mas também revisar e aprimorar estratégias continuamente, acompanhando o crescimento do sistema.

Essas lições são aplicáveis a qualquer sistema em crescimento e ilustram como desafios técnicos podem ser superados com planejamento estratégico e um mindset de aprendizado contínuo.