TigerBeetle é o banco de dados mais interessante do mundo
(amplifypartners.com)- O banco de dados de transações financeiras TigerBeetle é um novo banco de dados com suporte nativo a débito (debit) e crédito (credit) e, ao contrário dos bancos de dados SQL tradicionais, que exigiam de 10 a 20 consultas para uma única transação, processa 8.190 transações em um único roundtrip
- Enquanto inúmeros sistemas optam por codificação rápida e expansão de dependências, este projeto mantém estratégias contraintuitivas como escrever código devagar, Deterministic Simulation Testing (DST) e zero dependências
- Diferente dos bancos de dados OLTP tradicionais que dependem de uma arquitetura de nó único, ele incorporou ao projeto distribuição por padrão, tolerância a falhas de relógio (cluster time) e tolerância a falhas de armazenamento, além de garantir simplicidade de implementação e visibilidade com a escolha de Viewstamped Replication e Zig
- Aplica a metodologia TigerStyle, inspirada no Power of Ten da NASA, seguindo padrões rígidos de código, como uso médio de mais de 2 assertions por função, imposição de alocação estática de memória e assertions ativadas até mesmo em produção
- Com uma estrutura voltada para a era da hipertransacionalização, como pagamentos em tempo real, games e cobrança de energia, apresenta um novo referencial de desempenho e precisão para a próxima geração de OLTP e surge como um sistema de processamento transacional de nova geração capaz de substituir bancos de dados SQL com 20 a 30 anos de idade
A necessidade de um banco de dados centrado em débito/crédito
- O TigerBeetle é um "banco de dados de transações financeiras" que usa débito (debit) e crédito (credit) como primitivas centrais
- A essência da transação definida por Jim Gray em 1985 não era a transação SQL, mas a transação de negócio (débito/crédito)
- Mesmo 20 anos depois, Gray continuou definindo o processamento transacional padrão como "DebitCredit": debitar uma conta bancária, executar a escrituração em partidas dobradas e depois responder ao terminal
- Débito/crédito não serve apenas para contabilidade ou bancos, mas é uma linguagem comum que representa a essência da transação, razão pela qual oferece garantias como ACID
- Problemas ao implementar débito/crédito em bancos de dados SQL tradicionais
- Para processar um único débito/crédito, são necessárias 10 a 20 consultas SQL, como consulta de saldo, bloqueio de linha, espera por decisão no código e registro de débito/crédito
- É preciso manter o bloqueio da linha durante o tempo de ida e volta da rede, o que piora o problema de hot row quando muitas transações acessam a mesma "house account"
- Com bilhões de pagamentos instantâneos por mês na Índia e no Brasil, FedNow nos EUA e billing em tempo real em energia, games e cloud, o mundo se tornou pelo menos três ordens de grandeza mais orientado a transações em 10 anos, mas os bancos SQL usados hoje são tecnologia de 20 a 30 anos atrás
- Pontos de diferenciação do TigerBeetle
- Débito/crédito foi projetado como primitiva de primeira classe, permitindo processar 8.190 transações em uma única consulta de 1MiB com apenas um roundtrip
- O fundador Joran chama isso de uma "ideia de desempenho 1000x", mas diz que "não é nada de especial"
- Embora normalmente leve 10 anos para construir um banco de dados, o TigerBeetle foi concluído em 3,5 anos e passou nos testes Jepsen
- Em junho de 2025, Kyle Kingsbury não conseguiu quebrar os fundamentos do TigerBeetle mesmo corrompendo vários locais em todas as máquinas (foi encontrado apenas 1 bug de correção no motor de consultas de leitura, sem impacto na durabilidade)
Projeto moderno de banco de dados
Arquitetura distribuída por padrão
- Na época em que Postgres e MySQL foram construídos, o paradigma dominante era o de nó único, mas hoje, na era do hardware de cloud compartilhado, o paradigma principal é o distribuído
- Bancos de dados modernos precisam oferecer serialização estrita e replicar transações entre máquinas para garantir redundância, tolerância a falhas e alta disponibilidade
- Alguns dos bancos de dados OLTP mais populares ainda dependem fortemente de arquitetura de nó único, e em alguns casos não têm failover automático embutido por padrão
- O projeto distribuído do TigerBeetle
- Foi construído para ser distribuído por padrão: basta instalar o binário no número de máquinas desejado dentro do cluster
- Não precisa de replicação assíncrona, Zookeeper etc.; em vez disso, investe na implementação do protocolo de consenso pioneiro do MIT, Viewstamped Replication
- Mantém zero dependências além do toolchain do Zig e investe diretamente em todas as dependências essenciais
Tolerância a falhas de relógio
- Como banco de dados transacional, o TigerBeetle considera importante a precisão dos timestamps físicos para auditoria e conformidade
- O Linux tem vários relógios:
CLOCK_MONOTONIC_RAW,CLOCK_MONOTONIC,CLOCK_BOOTTIME - Por imperfeições físicas dos relógios de hardware, eles operam em velocidades diferentes, gerando erro de "drift", que em pouco tempo se acumula como erro de "skew"
- Em geral, o NTP corrige esses erros, mas se ele parar silenciosamente por uma falha parcial de rede, um cluster de consenso de alta disponibilidade pode continuar operando no escuro
- O Linux tem vários relógios:
- Implementação do cluster time
- Combina a maioria dos relógios do cluster para formar um relógio tolerante a falhas chamado "cluster time"
- Quando necessário, realinha o horário do sistema do servidor ou encerra com segurança se houver relógios defeituosos demais
- Detecta de fato quando Chrony, PTP e NTP pararam de funcionar e alerta o operador
- Rastreia e amostra horários de relógios com offset entre servidores e depois usa o algoritmo de Marzullo para estimar o intervalo mais preciso
Tratamento de falhas de armazenamento
-
Suposições dos bancos de dados tradicionais
- Assumem que, quando o disco falha, ele falha de forma previsível com uma mensagem de erro
- Documentação do SQLite: "O SQLite não adiciona redundância ao arquivo de banco de dados para detectar corrupção ou erros de I/O, e assume que os dados lidos são exatamente os mesmos que foram gravados anteriormente"
-
Cenários reais de falha de armazenamento
- O disco pode retornar dados corrompidos silenciosamente, encaminhar I/O na direção errada (caminho de leitura/escrita) ou apresentar gray failure, ficando repentinamente lento sem código de erro
-
Tolerância a falhas de armazenamento no TigerBeetle
- Usa Protocol Aware Recovery para manter a disponibilidade, desde que nem todas as cópias dos dados em todas as réplicas estejam corrompidas
- Todos os dados são imutáveis e checksums com hash chains oferecem forte garantia de ausência de corrupção ou adulteração
- Com page cache próprio, gravação em disco via O_DIRECT e execução direta sobre dispositivo de bloco bruto (sem necessidade de filesystem), minimiza as camadas entre o disco e o software
- Em vez de um LSM pronto, usa sua própria LSM Forest (cerca de 20 árvores LSM)
- Não apenas afirma tolerar falhas de armazenamento: é o único banco de dados distribuído validado pelo Jepsen nesse aspecto
- Quando há falha na máquina local, mesmo que apenas setores do disco falhem, o storage engine se conecta ao consenso global e se autocura por meio do cluster
Escolha da linguagem de programação Zig
-
Linguagens dos bancos de dados tradicionais
- O Postgres é escrito em C (anos 1970), o MySQL em C e C++ (1979), e o MSSQL também em C e C++
- As linguagens de programação evoluíram muito nos últimos 40 anos e, se fosse construído hoje, seria possível escolher Rust ou Zig
-
Por que o TigerBeetle escolheu Zig
- Permite aproveitar todo o ecossistema C e oferece excelente toolchain e compilador
- É fácil de escrever e especialmente fácil de ler, às vezes tão fácil quanto TypeScript, mas muito mais rápido
- Permite alocação estática de memória, um princípio central do TigerBeetle
- Excelente experiência para desenvolvedores e aprendizado rápido (o que permite entrar rapidamente no código-fonte do TigerBeetle)
- Integrantes iniciais da equipe Rust, como Matklad (criador do Rust Analyzer) e Brian Anderson (cofundador do Rust com Graydon), trabalham no TigerBeetle
- Em Rust, não usar alocação dinâmica de memória é "modo difícil", mas em Zig isso é fácil
Deterministic Simulation Testing e VOPR
Conceito básico de DST
-
Deterministic Simulation Testing (DST) é uma técnica inovadora de testes popularizada pela equipe do FoundationDB (hoje da Apple)
- É usada para desenvolver bancos de dados distribuídos mais seguros e com menos bugs em menos tempo do que antes
- Em sistemas distribuídos, existe uma combinação infinita de problemas de concorrência: perda de mensagens, ordem imprevisível de execução de threads etc.
- Testes unitários e de integração tradicionais não bastam, e a verificação formal é cara e lenta
-
Como o DST funciona
- Um simulador que executa deterministicamente quase todos os cenários possíveis que o sistema pode enfrentar em uma determinada linha do tempo
- Considera também fatores externos, como problemas de OS, rede e disco, além de diferentes atrasos
- Entrega anos de testes em pouco tempo (o próprio tempo se torna determinístico, permitindo loops
while true) - É especialmente adequado para bancos de dados (intensivos em I/O e não em computação)
- Os testes Jepsen são um subconjunto do que o DST consegue fazer
O VOPR do TigerBeetle
-
Visão geral do VOPR (Viewstamped Operation Replicator)
- É um cluster de testes desenvolvido internamente, cujo nome vem do simulador WOPR do filme WarGames
- Testa continuamente o TigerBeetle sob incontáveis condições diferentes, desde a forma como os nós elegem um líder até falhas individuais de estado e de rede
- Permite simular virtualmente um cluster distribuído inteiro em uma única thread
-
Escala do VOPR
- É o maior cluster de DST do planeta, rodando em 1.000 núcleos de CPU
- A escala é tão incomum que a Hetzner chegou a enviar um email especial para confirmar se queriam mesmo tantos núcleos
- O VOPR-1000 roda 24x7x365 para capturar condições raras o máximo possível antes da produção
- No simulador, o tempo é abstraído deterministicamente e acelerado em cerca de 700x, acumulando aproximadamente 2 mil anos de runtime de simulação por dia
Gamificação do DST
- O TigerBeetle transformou o DST em um jogo, permitindo experimentar diferentes cenários de falha a partir da resposta do sistema
- O jogo pode ser acessado em sim.tigerbeetle.com
- Ele roda instâncias reais do VOPR no navegador para simular o TigerBeetle
- Foi compilado para WebAssembly, e os engenheiros do TigerBeetle criaram um frontend de jogo para visualizar o sistema real
TigerStyle e Power of Ten
Metodologia TigerStyle
-
TigerStyle é a metodologia de engenharia do TigerBeetle, publicada no GitHub
- "Uma troca coletiva em evolução na interseção entre engenharia e arte, números e intuição humana, razão e experiência, primeiros princípios e conhecimento, precisão e poesia"
- Adota o conceito de "Biodigital Jazz" do filme Tron: Legacy: o entrelaçamento entre elementos humanos e digitais, a natureza caótica mas estruturada da "Grid" e a expressão do espírito improvisador do potencial humano dentro da tecnologia
- No TigerBeetle, esse é o espírito do código que injeta não apenas ciência, mas também arte
-
Impacto do TigerStyle
- Apresenta princípios de engenharia e código derivados do Power of Ten, o conjunto de princípios da NASA para escrever código perfeito
- Vai de temas como simplicidade e elegância até aplicações como convenções de nomenclatura
- Já começa a influenciar outras empresas, como Resonate e Turso
- Também foi discutido no podcast de Lex Fridman
Uso de assertions
-
Regra 5 do Power of Ten: Assertion
- O conceito de codificar explicitamente, ao mesmo tempo em que se escreve, a expectativa sobre o comportamento do código (não depois)
- Escrito como booleano em uma única linha: assert(a > b)
-
Regras de assertion do TigerStyle
- Fazer assert de todos os argumentos de função, valores de retorno, precondições e invariantes, com média mínima de 2 assertions por função
- Quando algo é importante e surpreendente, usar assertion em vez de comentário
- Fazer assert das relações entre constantes em tempo de compilação para verificar a integridade do projeto antes da execução do programa
- Fazer assert não apenas do que deve acontecer, mas também do espaço negativo que não se espera que aconteça (onde bugs interessantes podem surgir)
Como pensar sobre desempenho
-
Raciocinar e projetar o código é mais importante do que escrever código
- O momento ideal para resolver desempenho e conquistar vitórias gigantes de 1000x é na fase de projeto, exatamente quando ainda não é possível medir nem fazer profiling
-
Princípios de desempenho do TigerStyle
- Fazer matemática básica de guardanapo sobre as "quatro cores primárias" (rede, storage, memória e CPU) e as "duas texturas" (bandwidth e latência)
- Oferece dicas táticas como separar control plane e data plane, fazer batching de acessos e extrair hot loops como funções independentes para reduzir dependências do compilador
Experimente você mesmo
- O TigerBeetle aplica pesquisa moderna a um formato antigo para oferecer garantias sem precedentes de desempenho e confiabilidade
- É um motor OLTP moderno que combina modelagem nativa de crédito/débito, distribuição por padrão, tolerância a falhas de storage e relógio e garantia de qualidade baseada em DST
- Desenvolve uma forma de arte em engenharia de sistemas e storage sem esquecer de se divertir no processo
- Graças ao uso inteligente de DST, foi construído no padrão Jepsen em apenas alguns anos
- A instalação é simples com um único binário, e o script oficial de instalação simples permite começar rapidamente e experimentar com um comando curl
6 comentários
Se você pensar no motivo de um banco de dados não usar nós distribuídos, dá para entender por que o Postgres é de nó único
Pense no que é mais importante do que desempenho
Comentários do Hacker News
O TigerBeetle é excelente, mas vale notar que este texto foi escrito por uma firma de investimento que investiu no TigerBeetle link relacionado
Nos próximos meses devo continuar publicando posts assim; espero que as pessoas discutam mais ativamente, e fico pensando se seria melhor adicionar um disclaimer no topo, o que não seria difícil de fazer
O artigo está claramente publicado no site da firma de investimento como “Portfolio Spotlight”, então é preciso ajustar as expectativas
Não vou entrar muito no mérito do estilo de escrita, mas dá para perceber com muita facilidade que é um texto de investidor
Sou fã da busca do TigerBeetle por correção, de suas práticas de programação e de sua direção hiperespecializada, mas quero criticar alguns pontos do post
A explicação sobre multinó é um pouco enganosa. Independentemente do que o pessoal cloud-native diga, um único DB bem ajustado com um pooler de conexões já consegue lidar com um QPS enorme. Numa empresa anterior, durante uma manutenção, por engano concentramos todo o tráfego em uma única instância MySQL 8 RDS, e ela aguentou 80–90 mil QPS sem dificuldade. A instância nem era grande; bastou ajustar bem o schema, as queries e o ProxySQL/MySQL. No pico, com um writer e duas réplicas de leitura, 120 mil QPS também iam tranquilo
Se você usa NVMe local ao nó no servidor, é bem provável que o limite de CPU chegue antes
Quanto ao problema de redundância, qualquer RDBMS projetado para ambientes de rede acaba tendo recursos de failover e hot standby
O sistema de consensus do TigerBeetle é inteligente e não depende de componentes externos, mas ele não tenta lidar com rows grandes. Se processar milhares de transações de uma vez em um pacote de 1 MiB, pode viabilizar algo que um RDBMS tradicional não conseguiria
Essas críticas não pretendem diminuir o feito deles, e continuo profundamente impressionado com esse produto
Apontar os limites do protocolo de consenso é justamente o ponto central. O TigerBeetle quer separar e tratar apenas workloads dedicadas a transações, não substituir todos os bancos OLGP. A ideia é mover apenas os dados importantes para um banco transacional separado. Dá para ver uma abordagem parecida no TurboPuffer
É verdade que RDBMS modernos são rápidos o bastante, mas o caso de uso do TigerBeetle é um ambiente especial de alta contenção. Em testes reais, já demonstraram diretamente que, quando várias transações mexem na mesma conta, o throughput do cluster inteiro cai drasticamente. (Referência: comentário relacionado no HN)
Gosto muito do trabalho do Joran e da equipe em DST, percepção de sistemas distribuídos e testes de desempenho; a obsessão deles por minimizar dependências é especialmente impressionante (embora dê para argumentar que o sistema operacional também pode ser tratado como dependência)
Mas sempre tenho a sensação de que a forma como tratam OLTP geral (que a equipe chama de OLGP) é injusta. Por exemplo, usam como comparação apenas transações SQL de baixo desempenho, como se em transações financeiras só se usasse row locking, e descrevem isso como se todos ainda estivessem presos ao design de OLTP de 50 anos atrás
Na página oficial de desempenho, a contenção só pode ser reduzida até 1%. Não acho que lugares como a Stripe operem com 1% de contenção em seus bancos OLTP
Dá para construir sistemas que preveem contenção, lidam com isso de forma elegante e entregam throughput extremo de transações. Esses sistemas protegem o DB da contenção e permitem continuar escalando. Na prática, os números de throughput em sistemas de pagamento em grande escala são muito maiores que os da comparação oficial de desempenho
O marketing ignora principalmente esses pontos e trata tudo como se todo desenvolvedor apenas despejasse transações ingênuas, quando na realidade a maioria é composta por engenheiros muito mais sofisticados. No setor de pagamentos existe até a função de 'payments engineer'
O TigerBeetle é incrível, mas me incomoda esse padrão de marketing que induz a uma visão equivocada sobre outros sistemas OLTP
Obrigado pelo elogio
Você disse que a Stripe não tem 1% de contenção no banco OLTP, mas a Stripe é baseada em MongoDB. Comparar isso com RDBMS é comparar banana com laranja
Sobre considerar o sistema operacional uma dependência subjacente: já trabalhei com sistemas totalmente in-memory e persistentes até durante
kexec. Em situações em que nem syscalls se pode fazer, o sistema operacional com certeza também pode ser uma dependênciaFico curioso se você pode dar exemplos de otimizações que tratem isso com checagens condicionais no momento do commit, em vez de transações baseadas em lock
Consideramos usar o TigerBeetle, mas havia os seguintes obstáculos
Usamos Cloudflare Workers, e o app cliente do TigerBeetle não é suportado. Link da issue Talvez funcione com Cloudflare Containers, mas nosso workflow é centrado em Workers
Não há recurso de autenticação (
auth). No servidor (como VPS), só dá para restringir por IP, mas em ambiente serverless não há IP fixo issue relacionadaUma solução também pode ser autenticar IPs com chaves ECC via Wireguard
Na prática, em ambientes como Cloudflare Workers ou AWS Lambda, se 1000 workers abrirem conexão com o DB ao mesmo tempo, isso causa problemas. Então normalmente se resolve colocando um proxy ou uma camada de serviço na frente do DB. Como o proxy sabe como acessar o DB, ele não precisa se preocupar com a questão de auth na rede privada
Se você conversar com a equipe de soluções do TigerBeetle, talvez receba propostas de soluções customizadas, como autenticação em nível lógico com criptografia ponta a ponta
É difícil acreditar que em 2025 exista um DB sem autenticação. Se é um banco para finanças, no mínimo deveriam publicar no site orientações de como adicionar um proxy/camada de autenticação. Se não usa HTTP (o que não fica claro só pela documentação), todo mundo vai querer saber como acoplar um proxy de autenticação sem HTTP. Expor isso à internet nesse estado seria muito perigoso
Houve a pergunta: “Em 10 anos, o volume de transações aumentou mais de 1000 vezes, e o DB usado é SQL de 20–30 anos atrás. Será que aguenta?” Acho que sim, aguenta.
Mesmo software com 30 anos continuou sendo atualizado, e sua base foi projetada com robustez desde o início
Aqui é o Joran (TigerBeetle). Em workloads gerais, não há problema, mas no processamento de transações surgem problemas com row locks em SQL por causa da contenção em power law (veja a Lei de Amdahl). Colocamos no site uma calculadora de contenção para estimar teoricamente o limite máximo de desempenho calculadora de contenção
O DNS também foi publicado em 1983 e ainda hoje é a base da internet. Se os fundamentos forem bons, um sistema com mais de 30 anos ainda pode aguentar muito bem. SQL é suficientemente bom para a maioria das workloads
Nem sempre uma tecnologia nova e elegante será melhor do que uma tecnologia antiga, testada e comprovada. Às vezes parece até que engenheiros de software são os profissionais mais ‘sem memória’ da indústria
Quando se lida com dezenas de DBs em um sistema distribuído, transações distribuídas (como Sagas) são inevitáveis. Em cenários de máquina única, bancos relacionais continuam excelentes
Em hardware antigo faltava desempenho, mas agora a tecnologia evoluiu e tudo roda melhor e mais rápido
O FoundationDB também tem bastante em comum com a discussão sobre o TigerBeetle
Escrita de código lenta, DST, ausência de dependências, ambiente distribuído por padrão em produção, tolerância a erro de relógio com locking otimista, testes pesados do Jepsen, testes em nova linguagem (Flow) etc. Com FDB também dá para resolver problemas muito parecidos, e acho que o TigerBeetle deve ser mais otimizado para seu caso de uso
O único motivo de o FDB não ser popular é a falta de boas camadas bem construídas. Ainda assim, algumas pessoas estão desenvolvendo separadamente camadas de SQS, DynamoDB e SQLite
O verdadeiro motivo de o FDB não ser popular é a Apple. Lançaram em 2013, o produto agradou tanto que compraram a empresa, e todos os usuários existentes acabaram ficando sem serviço. Mesmo após o fim da exclusividade, a confiança não se recuperou
Estamos colaborando com a equipe do FDB e também preparando posts sobre DST
Fico curioso para saber o que aconteceu depois da aquisição
Literalmente acho que é 'the one true database'
Perguntei “por que nenhum hyperscaler usa FDB” e, ao procurar no GitHub, no fim vi que ele foi parar sob a Apple
Recentemente apliquei o estilo de desenvolvimento do TigerBeetle em Rust, Go etc., e quero recomendar isso com muita força
Um único ponto de entrada, dependências quase zero
CI local, com um único comando para rodar testes/cobertura/lint etc.
Passei a me interessar por introduzir simulação com testes property/snapshot/swarm
Distinção entre rápido/lento, e todos os testes usam seed de forma determinística
Limites superiores explícitos + operação com pools de recursos, o que também deixa o código com alocação dinâmica mais fácil de entender
Isso tudo graças aos vídeos e à documentação da equipe do TB
O trecho “mantemos assertions ligadas em produção” foi marcante
Eu nunca entendi por que as assertions eram desligadas. Se um assert falha em produção, você precisa saber na hora (modo de dizer)
Historicamente, desligar assertions trazia ganho de desempenho. Mas hoje em dia fazer algumas comparações a mais quase não tem impacto
Originalmente, assertions são checagens para impedir mau uso da API pelo desenvolvedor. Na etapa de entrada do usuário, é mais razoável transformar isso em lógica de negócio com mensagens de erro adequadas
Às vezes dá vontade de usar assertion até para coisas difíceis de checar. Por exemplo, verificar que uma lista está ordenada
O propósito original de assertions era checagem em tempo de compilação/teste. Se for para uso em prod, basta transformar em
if. Vale pensar seassertnão é apenas açúcar sintático convenienteEu gostaria que a equipe do TB divulgasse mais amplamente o modelo de double-entry para cenários além do financeiro. Ele é muito útil também para ações, ingressos de shows etc. Como a melhoria da API já acabou, agora é hora de mostrar aplicações
Trabalho bastante com SQL como analista, mas não sou desenvolvedor de código. Entendo em geral a explicação e as vantagens de desempenho. Tenho algumas dúvidas a) Como é exatamente a estrutura de dados do TigerBeetle? Não parece ser no formato de tabelas comum b) Como ele é usado se não dá para fazer queries SQL c) Como o modelo de double-entry se aplicaria a ações, ingressos etc.? Por exemplo, se um local tem 1000 ingressos e vende um, isso vai do inventário para caixa e de receita diferida para obrigação de performance? Ou antes de vender o ingresso não existe nenhuma entrada?
Também dá para implementar algo parecido com double-entry no Postgres
A frase “a maioria das equipes escreve código rápido, sofre com testes e acumula dependências” era, na verdade, o padrão há 25 anos. Antes de Google e Facebook introduzirem a cultura de “move fast and break things”, todo mundo desenvolvia de forma extremamente cuidadosa, com muito teste e mais lentamente. Espero que o TigerBeetle receba mais reconhecimento. O relatório do Jepsen também vale a leitura relatório do Jepsen
Vale esperar 25 anos para ver se o TigerBeetle vira o próximo Google, ou se um produto lento mas perfeito acaba sendo engolido por concorrentes mais rápidos
“Move fast and break things” era o lema do Facebook. O Google, na verdade, era obcecado por testes. Claro, é preciso atender a requisitos reais, e engenheiros muitas vezes inventam requisitos hipotéticos demais e acabam criando ineficiência. Entregar o produto rapidamente para usuários reais e incorporar o feedback vale muito mais do que lapidar infinitamente o produto ‘dentro de uma bolha’
Separadamente do conteúdo do texto acima, o próprio site do TigerBeetle também é bem impressionante.
Passa uma sensação de ser algo extremamente rápido e, em vez de parecer uma tecnologia pesada, o design tenta apresentar isso de um jeito mais leve e divertido, o que achei bem interessante.
Link: https://tigerbeetle.com
Corrigindo: olhando de novo, realmente tem um ar meio pesado. Ainda assim, achei esteticamente impressionante e quis compartilhar :)
Pois é. Como a animação é rápida, eles conseguem criar uma tela que não fica monótona sem atrapalhar a concentração no conteúdo. E também passa com bastante força a ideia de que o TigerBeetle é extremamente rápido kkk
Muito interessante.
O tempo das animações está configurado para ser bem mais curto do que em sites comuns. Dá para desenvolver isso dessa forma também...