Como estimar crescimento de storage com writes, replicação e retenção

Introdução

Sabe quando está tudo tranquilo, até o mês em que a conta chega? O storage estourou o orçamento, e ninguém sabe explicar de onde vieram os últimos terabytes.

Storage quase nunca parece um problema no começo. Só que dado tem uma manha: ele acumula — um log aqui, um evento ali, todo santo dia.

O que parece pequeno por segundo pode virar dezenas de gigabytes por dia e vários terabytes por ano — ainda mais quando entram replicação, retenção, backup e histórico.

Por isso, estimar storage não é sobre fazer uma conta perfeita — é sobre enxergar a ordem de grandeza antes que o crescimento vire custo, gargalo ou incidente em produção. O objetivo é estar preparado para o crescimento, não acertar o número exato.

A conta base do storage

Antes de pensar em banco de dados, disco, object storage, backup ou qualquer tecnologia específica, precisamos responder a uma pergunta mais básica: em que velocidade o sistema está produzindo dados?

Essa primeira conta depende de duas informações:

1. quantas gravações acontecem por segundo;
2. qual é o tamanho médio de cada gravação.

A partir delas, conseguimos calcular a taxa de geração de dados do sistema. Ainda não estamos considerando tempo de retenção, replicação, índices, backups ou estruturas internas do banco. Neste primeiro momento, queremos apenas entender quanto dado novo é produzido a cada segundo.

Não é a estimativa final, mas é o ponto de partida para todas as outras contas.

Writes por segundo

O primeiro passo é descobrir quantas operações realmente geram dados persistidos a cada segundo.

Aqui existe uma diferença importante entre RPS e writes por segundo: não são a mesma coisa.

Um sistema pode receber 1.000 requisições por segundo, mas grande parte delas pode ser composta por leituras, validações, consultas em cache ou operações que não persistem nenhuma informação.

O contrário também pode acontecer. Uma única requisição pode gerar várias escritas. A criação de um pedido, por exemplo, pode gravar o pedido, seus itens, um evento de auditoria, uma mensagem em uma fila e um log estruturado.

Para estimar storage, o que importa é a quantidade de operações que realmente produzem dados que serão armazenados.

Na prática, esse writes/s vem de uma medição (métricas reais do sistema) ou de uma estimativa de tráfego — usuários ativos (DAU) → requisições → escritas. Mas a conta de tráfego é um exercício à parte; aqui partimos direto das gravações.

Suponha que o sistema realize:

Isso significa que cinco novos registros, eventos, transações ou documentos são produzidos a cada segundo.

Tamanho médio da gravação

Depois, precisamos entender quanto pesa cada gravação.

Esse valor pode variar bastante dependendo do tipo de dado. Um evento simples pode ter poucos kilobytes. Uma transação com mais informações pode ser maior. Um log estruturado pode crescer rápido. Já um arquivo, imagem ou documento muda completamente a escala da conta.

Para uma primeira estimativa, usamos um tamanho médio.

Por exemplo:

Esse número não precisa ser perfeito no começo. O objetivo é encontrar uma ordem de grandeza.

Também é importante lembrar: aqui estamos falando do dado lógico, ou seja, do tamanho aproximado da informação gravada. Ainda não entraram na conta índices, réplica, backup, WAL, journal, snapshots ou qualquer overhead interno do storage.

Mesmo assim, essa estimativa já ajuda muito. É melhor trabalhar com um número aproximado do que ignorar o crescimento ou achar que o storage não é um problema, até que ele se torne um.

A primeira estimativa

Com essas duas informações, a conta base fica assim:

Usando o exemplo:

250 KB parece pouco. E, isoladamente, realmente é.

Mas estamos falando de apenas um segundo e de uma carga aparentemente pequena: cinco gravações de 50 KB. Quando esse mesmo ritmo continua durante o dia inteiro, todos os dias, o volume deixa de parecer tão inofensivo.

O problema do storage não costuma estar em uma gravação. Está no acúmulo.

Agora que temos a taxa de geração de dados, podemos colocar tempo nessa conta.

Aproximação e notação científica

Agora que sabemos quanto dado o sistema produz por segundo, precisamos entender o que acontece quando esse ritmo continua durante horas, dias, meses ou anos.

É nesse momento que números aparentemente pequenos começam a crescer rápido — e também quando as contas ficam cheias de zeros, conversões e unidades diferentes.

Aproximações e notação científica ajudam justamente nisso: simplificam o cálculo sem esconder a escala real do problema. Em vez de buscar precisão absoluta desde o primeiro passo, conseguimos chegar rapidamente a uma estimativa útil e entender para onde o volume está caminhando.

Por que aproximar

Em uma estimativa inicial de capacidade, o objetivo é descobrir a ordem de grandeza do problema. Queremos saber se o sistema produzirá megabytes, gigabytes, terabytes ou petabytes. Nesse momento, chegar a um número perfeitamente exato costuma ser menos importante do que conseguir concluir a conta e entender sua escala.

Um dia possui exatamente 86.400 segundos. Para simplificar uma estimativa rápida, podemos arredondar esse valor:

Regras rápidas

Antes de continuar a conta, vale deixar algumas referências simples à mão.

Na prática, isso significa que 1 GB = 1.000.000 KB. Por isso, quando temos um valor em KB e queremos chegar em GB, dividimos por 1.000.000.

A notação científica ajuda a escrever esses números de forma mais compacta:

Essas regras não precisam ser decoradas. Elas servem para deixar as contas grandes mais fáceis de acompanhar.

A conta rápida

No nosso exemplo, o sistema produz 250 KB de dados por segundo. Se ele mantiver esse ritmo durante aproximadamente 100.000 segundos, conseguimos estimar o volume diário.

Aproximado vs preciso

Na conta rápida, usamos 10⁵ segundos para representar um dia. Esse atalho nos levou a uma estimativa de 25 GB por dia.

Agora vamos refazer a mesma conta usando o valor real de segundos em um dia: 86.400.

Com o atalho, chegamos a 25 GB/dia. Com os segundos reais, chegamos a 21,6 GB/dia.

A conclusão geral continua parecida: nos dois casos, o sistema está produzindo dezenas de gigabytes por dia. Mas isso não significa que a diferença sempre possa ser ignorada.

Esse é o cuidado importante: uma diferença pequena por dia pode virar uma diferença grande quando acumulada. Aqueles 3,4 GB/dia viram cerca de 100 GB/mês e mais de 1 TB/ano — e isso ainda sem considerar replicação, backups, snapshots, índices, logs adicionais ou retenção maior.

Mesmo assim, usar 86.400 segundos não torna a estimativa perfeita. Ele apenas remove um arredondamento da conta.

Na prática, várias outras variáveis continuam mudando.

O sistema pode receber menos tráfego no fim de semana, ter picos em horário comercial, crescer em campanhas, datas específicas ou fechamento de mês. O tamanho médio dos dados também pode mudar conforme novos campos, logs, eventos e integrações entram no sistema.

Por isso, aproximação não significa descuido. Ela é uma primeira leitura da escala do problema, não uma garantia de capacidade.

Quando a decisão envolve orçamento de cloud, limite de disco, backup, SLA, provisionamento ou compromisso com cliente, precisamos refinar a conta com métricas reais, padrões de tráfego e cenários mais próximos da produção.

A regra prática é simples:

Use aproximações para entender a escala e valores mais precisos para assumir compromissos.

Seguimos com 25 GB/dia como base para acompanhar a evolução da conta; quando a decisão envolver orçamento ou provisionamento, troque por uma medição real (como os 21,6 GB/dia).

Tempo de retenção

Saber quanto dado o sistema produz por dia ainda não é suficiente.

Para manter a conta simples, vamos seguir com a estimativa rápida de 25 GB por dia. A próxima pergunta é: por quanto tempo esse volume precisa continuar armazenado?

Essa resposta muda completamente a estimativa. Guardar dados por 7 dias é uma coisa. Guardar dados por 1 ano é outra. Guardar por 5 anos já muda completamente o tamanho do problema.

Tempo de retenção é justamente isso: o período em que um dado precisa permanecer disponível antes de ser removido, arquivado ou movido para outro tipo de storage.

O que é retenção

Retenção é uma política que define por quanto tempo cada tipo de dado será mantido.

Nem todo dado precisa ficar armazenado pelo mesmo período. Logs técnicos podem ter uma retenção curta. Eventos de auditoria podem precisar ficar por meses ou anos. Arquivos enviados por usuários talvez precisem existir enquanto a conta estiver ativa. Dados financeiros, fiscais ou contratuais podem depender de regras de negócio, suporte, compliance ou obrigações legais.

Alguns exemplos comuns:

O ponto importante é: retenção não é apenas uma escolha técnica. Ela depende do produto, do negócio, da operação e, em alguns casos, de requisitos legais.

Por isso, antes de estimar storage, precisamos entender quais dados serão guardados e por quanto tempo.

Aplicando na conta

Até aqui, chegamos a uma geração diária de aproximadamente 25 GB por dia.

Para descobrir o volume acumulado, multiplicamos esse valor pelo tempo de retenção.

Agora o número começa a mudar de escala.

A taxa de 250 KB/s, que parecia pequena no começo, virou 25 GB por dia. Com apenas 30 dias de retenção, isso já representa 750 GB de dados lógicos acumulados.

Se a retenção for maior, o impacto cresce junto.

A mesma taxa de gravação pode gerar estimativas muito diferentes dependendo do tempo de retenção.

Essa é uma das partes mais importantes da estimativa: storage não cresce apenas porque o sistema recebe mais dados por segundo. Ele cresce porque esses dados permanecem acumulados.

Nem tudo precisa ficar para sempre

Um erro comum é assumir que tudo que foi gravado precisa ficar para sempre no storage principal.

Na prática, sistemas maduros costumam separar os dados por idade, importância e frequência de acesso.

Dados recentes geralmente precisam ficar mais acessíveis, porque são consultados com mais frequência pelo produto, suporte, relatórios ou operação. Dados antigos podem ser arquivados, compactados, agregados ou movidos para um storage mais barato. Dados que não precisam mais existir podem ser removidos.

Uma estratégia simples para o ciclo de vida dos dados pode ser dividida em três camadas:

Isso evita tratar todo dado da mesma forma.

Um log de debug antigo talvez não precise ocupar espaço no banco principal. Um evento analítico pode ser agregado depois de alguns meses. Um arquivo pouco acessado pode ir para uma camada de arquivamento. Um dado sensível pode exigir retenção mínima, não máxima.

A pergunta não é apenas:

quanto dado o sistema gera?

A pergunta correta é:

quanto dado precisa continuar disponível, em qual lugar, por quanto tempo e com qual nível de acesso?

Essa decisão muda custo, performance, backup, restore e complexidade operacional.

Por isso, tempo de retenção é uma das variáveis centrais da estimativa de storage. Ele transforma uma taxa diária em volume acumulado e prepara o próximo fator da conta: a replicação.

Replicação

Até agora, calculamos o volume lógico dos dados.

Com 25 GB por dia e 30 dias de retenção, chegamos a 750 GB. Esse número representa o tamanho dos dados como se existisse apenas uma cópia armazenada.

Mas muitos sistemas não mantêm apenas uma cópia.

Eles replicam os dados.

Replicação significa manter mais de uma cópia dos dados para aumentar disponibilidade, durabilidade ou tolerância a falhas.

Em vez de depender de um único disco, nó ou zona, o sistema mantém cópias adicionais. Assim, se uma parte da infraestrutura falhar, ainda existe outra cópia disponível.

O ponto importante para nossa estimativa é simples: cada cópia ocupa espaço.

Se o volume lógico é 750 GB e o sistema mantém três cópias dos dados, a conta fica assim:

A mesma informação continua sendo gerada pelo sistema. O que mudou foi a quantidade de cópias mantidas para proteger e disponibilizar esses dados.

Por isso, replicação entra como um multiplicador na conta.

Nesse exemplo, 750 GB parecia algo grande, mas ainda administrável. Com três cópias, o número já passa para 2,25 TB.

É aqui que muita estimativa inicial começa a ficar mais realista.

Para a conta de storage, o que importa é que são coisas diferentes — replicação multiplica o volume ativo; backup é armazenamento à parte, com conta própria. Backup não entra nesta estimativa de propósito: frequência, retenção e política variam demais por empresa, contrato e compliance para caber numa conta rápida. Seguimos só com a replicação; os outros fatores aparecem nos cuidados finais.

Fechando a conta

Agora podemos juntar as principais variáveis da estimativa.

No nosso exemplo, partimos de:

• 5 writes/s;
• 50 KB por gravação;
• aproximadamente 25 GB/dia;
• 30 dias de retenção;
• fator de replicação 3.

Esse é o ponto mais importante da conta: uma taxa pequena por segundo pode virar um volume grande quando acumulada no tempo e multiplicada por cópias.

A fórmula mental fica assim:

writes/s × tamanho médio × tempo de retenção × fator de replicação = storage estimado

Cuidados finais

A conta que fizemos ajuda a enxergar a ordem de grandeza, mas ela ainda não representa todo o consumo real de produção.

Alguns fatores podem aumentar, reduzir ou distorcer esse número:

Por isso, essa estimativa deve ser tratada como ponto de partida.

Ela ajuda a tomar decisões melhores, fazer perguntas mais cedo e evitar surpresas. Mas, antes de assumir orçamento, provisionar infraestrutura ou definir limites operacionais, o ideal é validar a conta com métricas reais do sistema.

Teste seu entendimento

Antes de fechar, que tal checar o que ficou? Cinco perguntas rápidas sobre os fatores da conta:

Conclusão

Storage não costuma virar problema por causa de uma única gravação.

Ele vira problema pelo acúmulo: pequenos registros, eventos, logs e históricos que continuam sendo gerados todos os dias, durante semanas, meses ou anos.

A estimativa não precisa ser perfeita para ser útil. Começar com writes/s, tamanho médio, tempo de retenção e fator de replicação já ajuda a enxergar a ordem de grandeza antes que o crescimento vire custo, gargalo ou incidente.

Depois, com métricas reais, a conta pode ser refinada.

O importante é não tratar storage como infinito, nem deixar essa conversa para quando o alerta de disco já estiver gritando em produção.

Estimar storage é menos sobre acertar o número exato e mais sobre não ser pego de surpresa.

Fica o convite: da próxima vez que subir um serviço novo, rabisque essa conta de guardanapo antes do primeiro deploy. Cinco minutos agora poupam aquele susto na fatura lá na frente.