Um sistema financeiro processa uma transação utilizando uma taxa de 2%. Dois dias depois, recebe uma correção informando que, na data daquela operação, a taxa contratualmente aplicável deveria ser de 1,5%. A informação está correta, a alteração é legítima e o sistema precisa refletir a nova condição. O problema é decidir o que fazer com o passado.
Se simplesmente atualizarmos a taxa no banco de dados, as consultas futuras passarão a mostrar 1,5%. Entretanto, uma auditoria poderá questionar por que a transação foi originalmente calculada com 2%. Se preservarmos apenas o valor anterior, o sistema continuará representando uma condição que sabemos estar incorreta. E, se recalcularmos silenciosamente todas as operações anteriores, podemos alterar resultados financeiros sem preservar a justificativa das decisões originais.
Esse é um problema de modelagem temporal. Ele aparece quando precisamos representar não apenas como uma informação muda ao longo do tempo, mas também como o conhecimento que temos sobre essa informação evolui.
Grande parte das aplicações foi construída assumindo que existe uma única versão relevante da verdade: o estado atual. Essa abstração funciona bem para inúmeros problemas, mas começa a falhar em domínios que envolvem correções retroativas, eventos atrasados, contratos com vigência, auditoria, decisões financeiras e reconstrução histórica.
Nesses cenários, saber o valor atual de uma propriedade não é suficiente. Precisamos distinguir o momento em que determinado fato era válido para o negócio do momento em que o sistema passou a conhecê-lo.
O problema de representar o tempo com uma única data
Considere uma plataforma que calcula taxas de serviço para seus clientes. Cada cliente possui uma condição contratual, e o valor da taxa pode mudar conforme renegociações comerciais.
Inicialmente, a implementação parece simples:
CREATE TABLE merchant_fees (
merchant_id BIGINT PRIMARY KEY,
fee_percent NUMERIC(5,2),
updated_at TIMESTAMPTZ
);Enquanto a aplicação precisa apenas calcular operações com a taxa atualmente cadastrada, esse modelo pode ser suficiente. A dificuldade aparece quando uma alteração não representa simplesmente uma nova condição a partir de agora.
Imagine a seguinte sequência:
- Em 25 de agosto, o sistema registra uma taxa de 2% para setembro.
- Em 1º de setembro, entra em vigor uma condição contratual de 1,5%, mas a atualização não chega ao sistema.
- Em 2 de setembro, uma transação é calculada utilizando 2%.
- Em 4 de setembro, a área responsável identifica a divergência e informa que a taxa de 1,5% era válida desde o dia 1º.
Ao final dessa sequência, existem duas perguntas diferentes.
A primeira é qual taxa deveria ser aplicada à transação de 2 de setembro, considerando as informações contratuais que possuímos hoje. A resposta é 1,5%.
A segunda é qual taxa estava registrada no sistema quando a transação foi processada. A resposta é 2%.
Ambas são necessárias para compreender o que aconteceu. Uma explica a regra de negócio que hoje reconhecemos como aplicável; a outra explica o estado de conhecimento sob o qual o sistema tomou a decisão original.
O campo updated_at não consegue representar sozinho essas duas perspectivas. Ele informa quando o registro foi atualizado, mas não descreve adequadamente a vigência da condição nem permite necessariamente recuperar as versões anteriores.
Essa diferença é o ponto de partida da modelagem temporal.
Tempo de validade e tempo de registro
Na literatura sobre bancos de dados temporais, existe uma distinção entre valid time e transaction time. Martin Fowler também utiliza os termos actual time e record time ao discutir o padrão Bitemporal History.
O primeiro representa quando determinada informação é considerada válida no domínio de negócio. O segundo representa quando essa informação passou a fazer parte do conhecimento registrado pelo sistema.
No exemplo da taxa, podemos representar as duas dimensões assim:
| Taxa | Vigência no negócio | Período em que essa versão era conhecida pelo sistema |
|---|---|---|
| 2,0% | A partir de 01/09 | De 25/08 até 04/09 |
| 1,5% | A partir de 01/09 | Desde 04/09 |
A sobreposição de vigência não é um erro. Ela representa uma mudança no nosso conhecimento sobre o mesmo período de negócio.
Até 4 de setembro, o sistema acreditava que a taxa aplicável ao dia 2 era de 2%. Depois da correção, passou a reconhecer que deveria ser de 1,5%.
Isso permite formular duas consultas que parecem semelhantes, mas possuem significados distintos.
Qual taxa consideramos hoje aplicável ao dia 2 de setembro? A resposta é 1,5%, considerando a versão corrigida do contrato.
Qual taxa o sistema considerava aplicável ao dia 2 de setembro quando consultado em 3 de setembro? A resposta é 2%.
A segunda pergunta é particularmente importante porque decisões passadas precisam ser avaliadas de acordo com o contexto que estava disponível no momento em que foram tomadas. Sem preservar esse contexto, corremos o risco de analisar decisões históricas utilizando informações que ainda não existiam para o sistema.
Fowler explora essa diferença em Bitemporal History, mostrando como uma correção retroativa altera nossa interpretação do histórico sem necessariamente apagar aquilo que acreditávamos anteriormente.
Existe uma nuance importante: tempo de validade não é uma garantia de que conhecemos uma verdade objetiva e definitiva. Ele representa a condição que o domínio atualmente reconhece como aplicável. Novas evidências podem modificar essa interpretação novamente, e o modelo precisa preservar a evolução desse conhecimento.
Como representar duas dimensões temporais no banco
Uma forma de lidar com esse problema é armazenar versões da informação associadas a dois intervalos de tempo. O primeiro determina quando a versão é válida para o negócio; o segundo determina durante qual período ela era considerada válida pelo sistema.
Um modelo relacional simplificado poderia possuir a seguinte estrutura:
CREATE TABLE merchant_fee_versions (
merchant_id BIGINT NOT NULL,
fee_percent NUMERIC(5,2) NOT NULL,
valid_from TIMESTAMPTZ NOT NULL,
valid_to TIMESTAMPTZ,
recorded_from TIMESTAMPTZ NOT NULL,
recorded_to TIMESTAMPTZ,
correction_reason TEXT,
CHECK (valid_to IS NULL OR valid_from < valid_to),
CHECK (recorded_to IS NULL OR recorded_from < recorded_to)
);Os campos valid_from e valid_to representam o intervalo de vigência no negócio. Já recorded_from e recorded_to representam o período durante o qual aquela versão fazia parte do estado conhecido pelo sistema. Um limite final nulo indica que o intervalo permanece aberto.
Quando chega uma correção retroativa, a versão anteriormente conhecida deixa de ser a versão corrente do conhecimento, mas permanece disponível para consultas históricas. A nova versão recebe sua própria vigência de negócio e um novo período de registro.
Essa atualização deve acontecer de maneira transacional e preservar integralmente as versões anteriores. Também é necessário impedir sobreposições indevidas dentro de uma mesma perspectiva de conhecimento, garantindo que uma consulta não encontre duas taxas contraditórias para o mesmo cliente e instante.
Com esses dados, conseguimos consultar uma versão histórica utilizando dois parâmetros temporais:
SELECT fee_percent
FROM merchant_fee_versions
WHERE merchant_id = $1
AND valid_from <= $2
AND (valid_to IS NULL OR $2 < valid_to)
AND recorded_from <= $3
AND (recorded_to IS NULL OR $3 < recorded_to);O parâmetro $2 representa a data de negócio que queremos consultar, enquanto $3 representa o momento de conhecimento sob o qual desejamos interpretar aquela data.
Para consultar a taxa válida em 2 de setembro conforme o conhecimento disponível em 3 de setembro, obteríamos 2%. Mantendo a data de negócio e alterando o momento de conhecimento para 5 de setembro, obteríamos 1,5%.
A convenção de intervalos utilizada é fechada no início e aberta no fim, representada matematicamente como [início, fim). Ela evita ambiguidades nas fronteiras entre versões consecutivas.
Esse exemplo demonstra o mecanismo, mas não constitui uma implementação completa de bitemporalidade. Um sistema de produção também precisa tratar concorrência, integridade entre intervalos, correções parciais de vigência, identidade das versões, proveniência, retenção e desempenho das consultas históricas.
Há recursos úteis nos bancos relacionais para esse tipo de problema. PostgreSQL, por exemplo, possui tipos de intervalo como tstzrange, além de operadores e restrições que ajudam a trabalhar com períodos temporais. Outros bancos oferecem mecanismos de versionamento histórico de registros. É importante, porém, verificar qual dimensão temporal cada recurso realmente implementa: preservar o histórico das alterações no banco não significa automaticamente representar a vigência dessas alterações no negócio.
Modelagem temporal não é simplesmente criar uma tabela de auditoria
Uma alternativa comum seria manter a tabela atual e registrar cada alteração em uma tabela de auditoria. Essa estratégia é perfeitamente válida quando o objetivo é descobrir quem alterou determinado campo e qual era seu valor anterior.
O problema aparece quando precisamos fazer consultas temporais como parte normal do domínio.
Imagine um relatório financeiro que precise calcular as condições contratuais aplicáveis a milhares de transações em diferentes datas, considerando o conhecimento disponível durante o fechamento original de determinado período.
Se o histórico existe apenas como uma sequência de operações de auditoria, a aplicação precisa reconstruir o estado a partir dessas mudanças. Isso pode ser trabalhoso, especialmente quando correções retroativas alteram intervalos e não apenas valores individuais.
Uma propriedade temporal oferece uma abstração diferente. Em vez de perguntar quais alterações ocorreram e reconstruir manualmente o resultado, consultamos diretamente qual valor era aplicável em determinado instante.
Fowler descreve essa abordagem no padrão Temporal Property, no qual uma propriedade deixa de ser interpretada apenas pelo valor atual e passa a oferecer acesso ao valor correspondente a uma data.
O ponto arquitetural é que temporalidade deixa de ser um detalhe técnico do armazenamento e passa a fazer parte do contrato do domínio.
Uma operação de negócio pode precisar perguntar feeAt(date) em vez de acessar simplesmente currentFee. Quando existe necessidade de reconstruir o conhecimento histórico, esse contrato pode incluir também o instante da perspectiva de registro.
Essa diferença evita que cada consumidor precise conhecer todos os detalhes das tabelas temporais e reduz o risco de diferentes partes do sistema interpretarem o histórico de maneiras incompatíveis.
O problema fica ainda mais complexo em sistemas distribuídos
Até aqui, consideramos uma correção retroativa em um banco de dados. Em sistemas distribuídos, existe uma dificuldade adicional: os eventos nem sempre chegam na ordem em que aconteceram.
Imagine uma operação de pagamento:
| Momento | Ocorrência |
|---|---|
| 14h00 | Pagamento autorizado |
| 14h02 | Serviço de pedidos registra pagamento pendente |
| 14h07 | Evento de autorização chega ao consumidor |
| 14h08 | Serviço de pedidos processa o evento |
Se analisarmos apenas quando o serviço de pedidos processou a mensagem, concluiremos que o pagamento foi autorizado às 14h08. Essa conclusão é incorreta. O evento ocorreu às 14h00, mas o serviço só tomou conhecimento dele posteriormente.
Nesse contexto, algumas datas possuem significados diferentes:
Event time representa quando o evento aconteceu na origem. Processing time representa quando determinado processador executou seu tratamento. Também podemos registrar quando a mensagem foi recebida, quando foi persistida localmente e quando seu efeito passou a valer para alguma regra de negócio.
Esses instantes podem coincidir, mas não são equivalentes.
A documentação de processamento temporal do Apache Flink distingue explicitamente event time e processing time, especialmente em cenários de eventos atrasados ou fora de ordem. O processamento baseado em tempo do evento permite associar uma ocorrência ao período em que ela efetivamente aconteceu, independentemente do momento em que foi recebida. Entretanto, exige políticas para determinar por quanto tempo o sistema aguardará eventos atrasados antes de considerar determinada janela suficientemente completa.
É nesse contexto que aparecem mecanismos como watermarks. Eles permitem representar o progresso do tempo dos eventos e estabelecer expectativas sobre a chegada de mensagens mais antigas.
Essa preocupação é especialmente relevante em analytics, antifraude, telemetria, conciliação financeira e processamento de grandes volumes de eventos.
Considere um indicador que conta pagamentos autorizados por minuto. Se utilizarmos o horário de processamento, um pagamento ocorrido às 14h00, mas recebido às 14h07, poderá ser contabilizado no minuto errado. Se utilizarmos event time, conseguimos associá-lo à janela correta, mas precisamos definir como tratar eventos que chegam depois do fechamento daquela janela.
A escolha não é meramente técnica. Em determinadas aplicações, aceitar correções posteriores é desejável. Em outras, existe uma exigência de fechamento operacional que precisa ser preservada.
Vale observar que event time e valid time também não são sinônimos universais. O primeiro normalmente descreve quando uma ocorrência aconteceu; o segundo descreve quando uma condição é aplicável no domínio. Uma renegociação contratual pode ser registrada hoje e possuir vigência futura, enquanto uma ocorrência financeira pode chegar atrasada sem que sua data de negócio tenha sido alterada.
Corrigir o passado não significa reescrever tudo o que aconteceu
Voltemos ao exemplo financeiro.
Depois de descobrir que a taxa correta era 1,5%, o sistema precisa preservar essa nova informação. Mas o que deve acontecer com as transações que já foram calculadas utilizando 2%?
Essa pergunta não pode ser respondida apenas pelo modelo de dados. Ela depende das regras do domínio.
Uma operação já liquidada representa um acontecimento real. Se o cliente foi cobrado em R$ 20,00 quando deveria ter sido cobrado em R$ 15,00, a descoberta posterior não significa que a cobrança original nunca aconteceu.
O registro da operação original precisa continuar refletindo aquilo que efetivamente foi executado. A correção pode gerar um ajuste financeiro, um crédito, uma restituição ou algum outro procedimento previsto contratualmente.
Isso significa que precisamos preservar informações de naturezas diferentes: qual regra deveria ter sido aplicada, qual regra o sistema conhecia, qual regra foi efetivamente utilizada e qual ajuste posterior corrigiu a divergência.
Em domínios financeiros, reescrever silenciosamente o lançamento original pode destruir justamente a informação necessária para explicar o ajuste.
Esse é um ponto em que modelagem temporal se encontra com contabilidade, auditoria e imutabilidade de eventos. Em alguns casos, a abordagem correta não é substituir o fato histórico, mas registrar uma nova ocorrência que modifica sua interpretação ou compensa seu efeito.
Também existe uma consequência para decisões automatizadas. Quando um serviço toma uma decisão a partir de determinada política, é útil preservar uma referência à versão utilizada ou um snapshot dos parâmetros decisivos. Assim, conseguimos reconstruir não apenas a regra que hoje consideramos aplicável, mas a regra que de fato orientou aquela execução.
Essa distinção importa porque dados temporais não tornam, por si só, qualquer decisão histórica reproduzível. Se outros parâmetros envolvidos na decisão foram alterados ou descartados, ainda poderemos perder parte do contexto necessário para explicá-la.
Nem todo sistema precisa de bitemporalidade
É importante não transformar esse conceito em uma nova regra arquitetural universal.
Muitas aplicações precisam apenas do estado atual. Outras precisam manter um histórico simples de alterações. Algumas necessitam representar períodos de vigência, mas não precisam consultar como o conhecimento sobre esses períodos mudou. Apenas uma parcela dos domínios realmente exige duas dimensões temporais completas.
Adicionar bitemporalidade possui custo.
As tabelas acumulam mais versões, as consultas ficam mais complexas e as operações de atualização precisam preservar invariantes temporais. Também é necessário considerar índices, retenção de histórico, políticas de correção e consistência entre múltiplas entidades consultadas no mesmo instante lógico.
Para um cadastro simples, esse custo pode não produzir benefício relevante.
Para contratos, preços com vigência, condições financeiras, regras regulatórias, benefícios, políticas de elegibilidade e determinados sistemas de auditoria, a situação é diferente. Nesses casos, conseguir reconstruir o passado pode fazer parte do comportamento esperado do produto.
Uma abordagem pragmática é escolher o nível de temporalidade a partir das perguntas que o negócio realmente precisa responder.
Se precisamos apenas saber quem alterou um campo, auditoria pode ser suficiente. E também precisamos consultar qual condição era válida em determinada data, um histórico com períodos de vigência resolve parte do problema. Se precisamos saber também o que o sistema acreditava naquela época, chegamos à necessidade de bitemporalidade.
O cuidado principal é não descobrir essa necessidade tarde demais. Quando sobrescrevemos informações históricas durante anos, não existe garantia de que conseguiremos reconstruí-las posteriormente. O histórico de conhecimento que nunca foi preservado pode simplesmente ter sido perdido.
A temporalidade também precisa aparecer nos contratos
Existe uma consequência arquitetural frequentemente ignorada: não adianta o banco suportar consultas históricas se APIs, eventos e serviços continuam tratando todas as datas como equivalentes.
Um contrato que expõe apenas updatedAt pode ser suficiente para informar quando determinado registro mudou, mas não permite distinguir quando uma regra passou a valer nem se a alteração representa uma correção retroativa.
Da mesma forma, um evento que informa apenas status = PAID e um timestamp genérico pode deixar consumidores sem saber se aquele horário representa a ocorrência, a publicação ou o processamento do pagamento.
Contratos mais claros explicitam a semântica temporal quando ela é relevante. Uma alteração contratual pode possuir início de vigência e momento de registro. Uma transação pode preservar o instante da autorização e o instante da confirmação. Um evento pode informar o momento da ocorrência, enquanto o consumidor registra separadamente quando tomou conhecimento dela.
Isso não significa adicionar cinco timestamps a todos os objetos.
Significa evitar que um único campo chamado date ou updatedAt carregue responsabilidades conceitualmente diferentes.
Também é importante definir convenções consistentes de fuso horário, precisão e origem dos relógios. Em sistemas distribuídos, timestamps não garantem por si só uma ordem causal confiável entre todas as operações. Quando a ordem exata é relevante, pode ser necessário combinar tempo com sequências, versões ou outros mecanismos de ordenação.
Modelagem temporal começa no domínio, mas precisa ser preservada até as fronteiras de integração.
O passado tem mais de uma versão
O modelo tradicional de estado atual funciona bem enquanto conseguimos tratar cada atualização como substituição definitiva de uma informação anterior. O problema é que o mundo real não opera sempre dessa maneira.
Contratos são corrigidos retroativamente. Eventos chegam atrasados. Dados são retificados. Decisões são tomadas com informação incompleta. Sistemas diferentes descobrem o mesmo fato em momentos distintos, e auditorias precisam reconstruir não apenas o resultado final, mas o contexto que levou até ele.
A modelagem temporal oferece uma maneira de tratar essas situações sem esconder suas diferenças.
Ao separar vigência de negócio e histórico de registro, conseguimos responder tanto qual condição consideramos aplicável a determinado instante quanto qual condição o sistema reconhecia naquele momento. Quando associamos esse modelo a eventos, decisões e ajustes imutáveis, também conseguimos explicar o que foi realmente executado e por que uma correção posterior se tornou necessária.
Não é uma complexidade que toda aplicação precisa carregar. É uma complexidade que determinados domínios já possuem, independentemente de nosso banco de dados estar preparado para representá-la.
O principal erro arquitetural é simplificar o modelo a ponto de descartar uma informação que o negócio precisará recuperar depois.
Por isso, antes de adicionar mais um updated_at, vale fazer duas perguntas:
Quando essa informação era válida para o negócio? E desde quando o sistema sabia disso?
Quando as respostas podem ser diferentes, uma única linha do tempo provavelmente já não é suficiente.
Referências
- Martin Fowler. Bitemporal History. Explica a separação entre histórico de validade e histórico de conhecimento, incluindo correções retroativas.
- Martin Fowler. Temporal Patterns e Temporal Property. Abordam padrões para representar e consultar propriedades que mudam ao longo do tempo.
- PostgreSQL. Range Types. Documentação dos tipos de intervalo, limites temporais e operadores de comparação.
- Apache Flink. Timely Stream Processing. Diferencia event time, processing time, eventos atrasados e watermarks.
- Microsoft Learn. Temporal Tables. Apresenta versionamento histórico de registros e consultas de estados passados.
