Projetar uma infraestrutura financeira de alta precisão é um dos maiores desafios em nuvem. A arquitetura de faturamento da Atlassian para o Forge, sua plataforma serverless, exemplifica como traduzir trilhões de sinais de execução distribuídos em registros financeiros impecáveis sem sobrecarregar a infraestrutura e sem gerar cobranças indevidas para os clientes.
Para desenvolvedores, arquitetos de software e engenheiros de DevOps no Brasil que lidam com o ecossistema de SaaS (Software as a Service), entender essa engenharia é um divisor de águas. O aumento na adoção de modelos de precificação baseados em consumo (usage-based pricing) exige que os times de tecnologia saibam como capturar telemetria operacional e convertê-la em dados transacionais seguros.
O desafio do faturamento em alta escala e por que ele falha
Quando uma plataforma serverless executa milhões de funções por segundo, calcular o custo exato de CPU, memória, armazenamento e chamadas de API torna-se uma tarefa complexa. Sistemas de faturamento tradicionais, baseados em bancos de dados relacionais e processamento em lote (batch), simplesmente entram em colapso sob esse volume de dados. Se cada execução de função exigisse uma gravação síncrona em um banco de dados SQL tradicional, o faturamento se tornaria o gargalo de desempenho de toda a nuvem.
Além disso, sistemas distribuídos são propensos a falhas parciais de rede. Mensagens podem ser duplicadas, pacotes de telemetria podem chegar fora de ordem e servidores de processamento podem cair no meio de uma transação. Se a arquitetura não for resiliente a esses cenários, a empresa enfrentará dois problemas graves: perda de receita devido a eventos não contabilizados ou, pior, a insatisfação dos clientes causada por cobranças duplicadas.
A engenharia por trás do UTS (Usage Tracking Service) da Atlassian
Para resolver a escala global do Forge, a Atlassian estruturou seu sistema em torno do UTS (Usage Tracking Service). O UTS funciona como o cérebro da arquitetura de faturamento, atuando de forma totalmente desacoplada dos ambientes de execução de código. Esse desacoplamento é o que garante que uma oscilação no sistema de cobrança nunca afete o desempenho das aplicações dos usuários finais.
O papel do Apache Kafka no desacoplamento de sinais
O fluxo começa quando as funções serverless emitem sinais de uso. Em vez de enviar esses dados diretamente para um banco transacional, os sistemas emitem eventos brutos para tópicos do Apache Kafka. O Kafka atua como uma camada de streaming resiliente, capaz de absorver picos massivos de tráfego sem perda de mensagens.
A Atlassian utiliza esquemas compartilhados (shared schemas) bem definidos para esses eventos. Isso significa que, independentemente de o sinal de uso vir de um banco de dados, de uma execução de função Javascript ou do consumo de banda de rede, todos os dados seguem a mesma estrutura de contrato. Isso simplifica drasticamente as regras de processamento e normalização dentro do UTS.
Idempotência e janelas de tempo: blindando o sistema contra duplicidade
Um dos maiores problemas do faturamento baseado em streaming de eventos é a garantia de entrega. O Kafka frequentemente trabalha com o modelo de entrega pelo menos uma vez (at-least-once). Isso significa que, em caso de instabilidade na rede, um mesmo evento de uso pode ser entregue duas ou mais vezes ao UTS.
Para evitar cobranças duplicadas, o UTS implementa mecanismos rigorosos de idempotência. Cada evento emitido recebe um identificador único universal (UUID) na origem. Ao processar o evento, o UTS verifica em uma camada de cache distribuído de baixíssima latência (geralmente baseada em Redis ou tecnologias similares) se aquele UUID específico já foi processado no ciclo atual. Se o ID já existir, o evento duplicado é descartado silenciosamente.
Além disso, o sistema trabalha com o conceito de processamento por janelas de tempo (windowed processing). Como os eventos podem atrasar devido à latência da internet ou problemas no cliente, o UTS agrupa o consumo em blocos temporais específicos. Eventos que chegam atrasados (late-arriving events) são enquadrados retroativamente na janela correta de faturamento, evitando que o fechamento mensal da fatura seja corrompido ou exiba valores inconsistentes.
Comparativo técnico: Modelos de Faturamento em Alta Escala
| Métrica / Abordagem | Faturamento Tradicional (Batch) | Arquitetura Orientada a Eventos (Kafka + UTS) |
|---|---|---|
| Latência de Processamento | Alta (horas ou dias para consolidar) | Quase tempo real (segundos a minutos) |
| Resiliência a Falhas | Baixa (se o job batch falhar, atrasa todo o ciclo) | Alta (desacoplamento via filas e partições) |
| Garantia de Cobrança | Suscetível a perda de dados sob picos de tráfego | Idempotência rigorosa e retenção no Kafka |
| Visibilidade para o Usuário | Apenas no fechamento da fatura mensal | Dashboards atualizados em tempo real |
Arraste para o lado para ver toda a tabela.
Impacto prático para o ecossistema brasileiro de SaaS e FinOps
No mercado de tecnologia brasileiro, a evolução dessas arquiteturas acelera diretamente a cultura de FinOps (Financial Operations). Quando empresas de tecnologia locais conseguem rastrear de forma granular o consumo de seus recursos de nuvem, elas podem precificar seus serviços de maneira muito mais justa e competitiva.
Para engenheiros de software no Brasil, dominar esses conceitos é o que diferencia profissionais seniores de especialistas em alta disponibilidade. Vagas que exigem experiência em arquitetura de microsserviços, streaming de dados com Kafka e modelagem de sistemas transacionais resilientes estão entre as mais valorizadas e com maior escassez de profissionais qualificados no país.
“A precisão no faturamento de sistemas SaaS não é apenas uma questão financeira; é um fator crítico de confiança e experiência do cliente. Erros de cobrança destroem a reputação de um produto mais rápido do que pequenos bugs de interface.”
Como projetar sistemas de cobrança distribuídos: Lições para arquitetos
Se você está desenhando ou modernizando a infraestrutura de faturamento da sua empresa, siga as melhores práticas validadas por gigantes como a Atlassian:
Desacople a emissão de sinais: Seus microsserviços de negócio nunca devem interagir diretamente com o processamento financeiro. Deixe que eles apenas emitam eventos de uso brutos.
Defina contratos de eventos consistentes: Use tecnologias como Protocol Buffers ou Apache Avro para gerenciar o esquema dos eventos e garantir que mudanças no código não quebrem o processamento do faturamento.
Trate a idempotência como prioridade máxima: Desenhe suas APIs e consumidores de mensagens para serem nativamente idempotentes. Um erro de duplicidade em faturamento custa muito caro para o suporte técnico e para o financeiro.
Monitore a latência dos dados: Tenha ferramentas de observabilidade para rastrear a diferença de tempo entre o momento em que o evento ocorreu e o momento em que ele foi processado pelo sistema de faturamento.
Perguntas frequentes sobre arquitetura de faturamento baseada em eventos
O que é o UTS (Usage Tracking Service) mencionado no ecossistema da Atlassian?
O UTS é o serviço responsável por receber, validar, normalizar e enriquecer os eventos brutos de consumo de recursos. Ele garante que cada métrica de uso seja corretamente associada ao cliente correspondente antes de enviar as informações consolidadas para os sistemas comerciais de cobrança.
Por que o Apache Kafka é preferido em vez de bancos de dados tradicionais para essa tarefa?
O Apache Kafka lida extremamente bem com altos volumes de escrita e processamento assíncrono. Ele atua como um buffer que absorve picos de tráfego de telemetria, garantindo que o sistema de faturamento seja resiliente e não sofra com gargalos que poderiam derrubar a aplicação principal.
O que acontece se um evento de faturamento for duplicado na rede?
Graças ao design de eventos idempotentes e ao controle por chaves únicas de transação, o sistema identifica que a mensagem já foi processada anteriormente e descarta a cópia extra, garantindo que o cliente final seja cobrado apenas uma vez pelo recurso consumido.
O que é o conceito de processamento por janelas de tempo?
É uma técnica de engenharia de dados que agrupa eventos que ocorreram dentro de um intervalo específico (por exemplo, a cada hora ou dia), independentemente do momento exato em que eles chegaram ao servidor de destino. Isso ajuda a acomodar mensagens atrasadas devido a problemas de conexão do usuário.
Como essa arquitetura ajuda a reduzir custos de infraestrutura em nuvem?
Ao rastrear o consumo com alta precisão, os times de engenharia conseguem aplicar práticas de FinOps mais eficientes, identificando desperdícios de recursos ociosos, otimizando o provisionamento de servidores e oferecendo planos de preços mais adequados ao real uso de cada cliente.
