TigerBeetle es la base de datos más interesante del mundo
(amplifypartners.com)- TigerBeetle, una base de datos para transacciones financieras, es una nueva base de datos con soporte nativo para débito (debit) y crédito (credit) y, a diferencia de las bases de datos SQL tradicionales que requerían entre 10 y 20 consultas para una sola transacción, puede procesar 8,190 transacciones en un solo roundtrip
- Mientras innumerables sistemas optan por programar rápido y expandir dependencias, este proyecto se aferra a estrategias contraintuitivas como escribir código lentamente, pruebas de simulación determinística (DST) y cero dependencias
- A diferencia de las bases de datos OLTP tradicionales que dependen de una arquitectura de nodo único, integra en su diseño distribución por defecto, tolerancia a fallas del reloj (cluster time) y tolerancia a fallas de almacenamiento, y asegura simplicidad de implementación y visibilidad mediante Viewstamped Replication y la elección de Zig
- Aplica la metodología TigerStyle, inspirada en Power of Ten de la NASA, y cumple estándares estrictos de programación, como usar en promedio más de 2 assertions por función, forzar asignación estática de memoria y mantener assertions activadas incluso en producción
- Con una estructura pensada para la era de la hipertransaccionalidad —como pagos en tiempo real, gaming y cobro de energía—, propone un nuevo referente de rendimiento y precisión para la próxima generación de OLTP y emerge como un sistema de procesamiento transaccional de nueva generación capaz de reemplazar bases de datos SQL de hace 20 a 30 años
La necesidad de una base de datos centrada en débito/crédito
- TigerBeetle es una "base de datos para transacciones financieras" que usa débito (debit) y crédito (credit) como primitivas centrales
- La esencia de la transacción definida por Jim Gray en 1985 no era la transacción SQL, sino la transacción de negocio (débito/crédito)
- Incluso 20 años después, Gray definía el procesamiento transaccional estándar como "DebitCredit": aplicar un débito a una cuenta bancaria, realizar contabilidad de partida doble y luego responder al terminal
- Débito/crédito no es solo para contabilidad o banca, sino un lenguaje común que representa la esencia de las transacciones y la razón por la que se ofrecen garantías como ACID
- Problemas al implementar débito/crédito con bases de datos SQL tradicionales
- Para procesar un solo débito/crédito se requieren 10 a 20 consultas SQL: consultar saldo de cuenta, bloquear filas, esperar decisiones en el código, registrar débito/crédito, etc.
- Hay que mantener bloqueos de fila durante los tiempos de ida y vuelta de red, lo que empeora el problema de hot row cuando muchas transacciones acceden a la misma "cuenta concentradora"
- Con decenas de miles de millones de pagos instantáneos mensuales en India y Brasil, FedNow en EE. UU., y facturación en tiempo real en energía, gaming y nube, el mundo se volvió al menos de tres dígitos más orientado a transacciones en 10 años, pero las bases de datos SQL que usamos hoy son tecnología de hace 20 a 30 años
- Puntos diferenciadores de TigerBeetle
- Diseña débito/crédito como primitivas de primera clase, permitiendo procesar 8,190 transacciones en una sola consulta de 1MiB y en un único roundtrip
- Su fundador, Joran, lo llama una "idea de rendimiento 1000x", aunque dice que "no tiene nada de especial"
- Normalmente una base de datos tarda 10 años en construirse, pero TigerBeetle se completó en 3.5 años y pasó las pruebas de Jepsen
- En junio de 2025, Kyle Kingsbury no pudo romper los fundamentos de TigerBeetle incluso corrompiendo varias ubicaciones en todas las máquinas (solo encontró un bug de exactitud en el motor de consultas de lectura que no afectaba la durabilidad)
Diseño moderno de bases de datos
Arquitectura distribuida por defecto
- En la época en que se construyeron Postgres y MySQL dominaba el paradigma de nodo único, pero hoy, en la era del hardware compartido en la nube, el paradigma dominante es el distribuido
- Las bases de datos modernas deben ofrecer serialización estricta y replicar transacciones entre máquinas para asegurar redundancia, tolerancia a fallas y alta disponibilidad
- Algunas de las bases de datos OLTP más populares hoy todavía dependen fuertemente de una arquitectura de nodo único, y en ciertos casos ni siquiera traen failover automático integrado por defecto
- Diseño distribuido de TigerBeetle
- Fue construida para ser distribuida por defecto: basta con instalar el binario en tantas máquinas del clúster como se desee
- No requiere replicación asíncrona ni Zookeeper; en su lugar, invierte en implementar el protocolo pionero de consenso de MIT, Viewstamped Replication
- Mantiene cero dependencias aparte del toolchain de Zig e invierte directamente en todas las dependencias clave
Tolerancia a fallas del reloj
- Como base de datos transaccional, TigerBeetle considera importante la precisión de los timestamps físicos para auditoría y cumplimiento normativo
- Linux tiene varios relojes:
CLOCK_MONOTONIC_RAW,CLOCK_MONOTONIC,CLOCK_BOOTTIME - Por imperfecciones físicas del hardware, los relojes funcionan a distintas velocidades, causando errores de "drift" que en poco tiempo se acumulan como errores de "skew"
- Normalmente NTP corrige estos errores, pero si NTP se detiene silenciosamente por una falla parcial de red, un clúster de consenso de alta disponibilidad puede seguir operando a ciegas
- Linux tiene varios relojes:
- Implementación de tiempo de clúster
- Combina la mayoría de los relojes dentro del clúster para formar un reloj tolerante a fallas llamado "cluster time"
- Si hace falta, vuelve a alinear la hora del sistema del servidor o se apaga de forma segura si hay demasiados relojes defectuosos
- Detecta realmente cuándo Chrony, PTP o NTP dejan de funcionar y alerta al operador
- Rastrea y muestrea la hora compensada entre servidores, y luego usa el algoritmo de Marzullo para estimar el intervalo más preciso
Manejo de fallas de almacenamiento
-
Suposiciones de las bases de datos tradicionales
- Asumen que cuando un disco falla, lo hará de manera predecible con un mensaje de error
- Documentación de SQLite: "SQLite no añade redundancia al archivo de base de datos para detectar corrupción o errores de I/O, y asume que los datos leídos son exactamente iguales a los datos previamente escritos"
-
Escenarios reales de fallas de almacenamiento
- Un disco puede devolver datos corruptos silenciosamente, redirigir mal I/O (ruta de lectura/escritura) o volverse repentinamente lento sin código de error, una gray failure
-
Tolerancia a fallas de almacenamiento en TigerBeetle
- Usa Protocol Aware Recovery, manteniendo la disponibilidad mientras no se corrompan las copias de datos en todas las réplicas
- Todos los datos son inmutables y, con checksums y hash chains, ofrece una fuerte garantía de que no hubo corrupción ni manipulación
- Minimiza las capas entre el disco y el software con su propio page cache, escritura a disco con O_DIRECT y ejecución directa sobre dispositivos de bloques crudos (sin necesidad de filesystem)
- En vez de usar un LSM comercial, emplea su propio LSM Forest (aproximadamente 20 árboles LSM)
- No solo afirma tolerancia a fallas de almacenamiento, sino que es la única base de datos distribuida validada por Jepsen en este aspecto
- Si falla una máquina local, incluso un fallo en un sector del disco conecta el motor de almacenamiento con el consenso global para permitir autorrecuperación a través del clúster
Elección del lenguaje de programación Zig
-
Lenguajes de las bases de datos tradicionales
- Postgres está escrito en C (años 70), MySQL en C y C++ (1979), y MSSQL también en C y C++
- Los lenguajes de programación han avanzado mucho en los últimos 40 años, y si se construyera algo moderno hoy se podría elegir Rust o Zig
-
Por qué TigerBeetle eligió Zig
- Permite aprovechar todo el ecosistema C y ofrece un excelente toolchain y compilador
- Es fácil de escribir y especialmente fácil de leer; en algunos casos, tan fácil como TypeScript pero mucho más rápido
- Permite asignación estática de memoria, uno de los principios clave de TigerBeetle
- Ofrece una gran experiencia de desarrollo y se aprende rápido (por lo tanto, se puede entrar rápido al código fuente de TigerBeetle)
- En TigerBeetle trabajan figuras como Matklad (miembro inicial del equipo de Rust y creador de Rust Analyzer) y Brian Anderson (cofundador de Rust junto a Graydon)
- En Rust, no usar asignación dinámica de memoria es "modo difícil", pero en Zig es fácil
Deterministic Simulation Testing y VOPR
Concepto básico de DST
-
Deterministic Simulation Testing (DST) es una técnica innovadora de pruebas popularizada por el equipo de FoundationDB (hoy propiedad de Apple)
- Se usa para desarrollar bases de datos distribuidas más seguras y con menos bugs en menos tiempo que antes
- En sistemas distribuidos existe una combinación infinita de problemas de concurrencia: pérdida de mensajes, orden impredecible de ejecución de hilos, etc.
- Las pruebas unitarias e integrales tradicionales no bastan, y la verificación formal es costosa y lenta
-
Cómo funciona DST
- Es un simulador que ejecuta determinísticamente casi todos los escenarios posibles que el sistema podría enfrentar en una línea temporal específica
- También considera factores externos como el SO, la red, problemas de disco o distintas latencias
- Ofrece años de pruebas en poco tiempo (el propio tiempo se vuelve determinista, así que son posibles bucles
while true) - Es especialmente apto para bases de datos (intensivas en I/O, no en cómputo)
- Las pruebas de Jepsen son un subconjunto de lo que DST puede hacer
VOPR de TigerBeetle
-
Resumen de VOPR (Viewstamped Operation Replicator)
- Es su clúster de pruebas desarrollado internamente, cuyo nombre viene del simulador WOPR de la película WarGames
- Prueba continuamente TigerBeetle bajo innumerables condiciones distintas, desde cómo los nodos eligen líder hasta fallas individuales de estado y de red
- Puede simular virtualmente un clúster distribuido completo en un solo hilo
-
Escala de VOPR
- Es el clúster DST más grande del planeta y corre en 1,000 núcleos de CPU
- Es tan inusualmente grande que Hetzner llegó a enviar un correo especial para confirmar si realmente querían tantos núcleos
- VOPR-1000 corre 24x7x365 para capturar tantas condiciones raras como sea posible antes de producción
- En el simulador, el tiempo se abstrae de forma determinista y se acelera unas 700 veces, acumulando aproximadamente 2 mil años de runtime de simulación por día
Gamificación de DST
- TigerBeetle convirtió DST en un juego, permitiendo experimentar distintos escenarios de falla a través de la respuesta del sistema
- El juego puede jugarse en sim.tigerbeetle.com
- Ejecuta una instancia real de VOPR en el navegador para simular TigerBeetle
- Está compilado a WebAssembly, y los ingenieros de TigerBeetle construyeron el frontend del juego para visualizar el sistema real
TigerStyle y Power of Ten
Metodología TigerStyle
-
TigerStyle es la metodología de ingeniería de TigerBeetle y está publicada en GitHub
- "Un intercambio colectivo en evolución en la intersección entre ingeniería y arte, números e intuición humana, razón y experiencia, primeros principios y conocimiento, precisión y poesía"
- Adopta el concepto de "Biodigital Jazz" de la película Tron: Legacy: el entrelazamiento de lo humano y lo digital, la naturaleza caótica pero estructurada del "Grid" y la expresión del espíritu improvisador del potencial humano dentro de la tecnología
- En TigerBeetle, el espíritu del código incorpora no solo ciencia, sino también arte
-
Influencia de TigerStyle
- Presenta principios de ingeniería y código derivados de Power of Ten, los principios de la NASA para escribir código perfecto
- Abarca desde temas como simplicidad y elegancia hasta aplicaciones como la forma de nombrar
- Ya empezó a influir en otras empresas como Resonate y Turso
- También se discutió en el pódcast de Lex Fridman
Uso de assertions
-
Regla 5 de Power of Ten: Assertion
- El concepto de codificar explícitamente al mismo tiempo las expectativas sobre el comportamiento del código (no después)
- Se escribe en una sola línea como booleano: assert(a > b)
-
Reglas de assertions en TigerStyle
- Hace assert de todos los argumentos de función, valores de retorno, precondiciones e invariantes, con un promedio mínimo de 2 assertions por función
- Cuando una assertion es importante y sorprendente, se usa una assertion en vez de un comentario
- Hace assert de las relaciones entre constantes de tiempo de compilación para verificar la integridad del diseño antes de ejecutar el programa
- Hace assert no solo de lo que debe ocurrir, sino también del espacio negativo de lo que no se espera (donde pueden aparecer bugs interesantes)
Pensamiento sobre rendimiento
-
Más importante que escribir código es razonar y diseñar el código
- El mejor momento para resolver rendimiento y conseguir enormes ganancias de 1000x es la etapa de diseño, justo cuando no se puede medir ni perfilar
-
Principios de rendimiento de TigerStyle
- Hacer matemáticas básicas de servilleta sobre "cuatro colores primarios" (red, almacenamiento, memoria y CPU) y "dos texturas" (ancho de banda y latencia)
- Ofrece consejos tácticos como distinguir el control plane del data plane, agrupar accesos por lotes y extraer hot loops como funciones independientes para reducir dependencias del compilador
Pruébalo directamente
- TigerBeetle aplica investigación moderna a un formato antiguo para ofrecer garantías inéditas de rendimiento y confiabilidad
- Es un motor OLTP moderno que combina modelado nativo de crédito/débito, distribución por defecto, tolerancia a fallas de almacenamiento y reloj y aseguramiento de calidad basado en DST
- Desarrolla una forma de arte en torno a la ingeniería de sistemas y almacenamiento, sin olvidar divertirse en el proceso
- Gracias a un uso inteligente de DST, se construyó con estándar Jepsen en apenas unos años
- La instalación es sencilla con un solo binario, y se puede empezar rápido y probarlo con solo un comando
curlmediante el simple script de instalación del sitio oficial
6 comentarios
Si piensas en por qué una base de datos no usaría nodos distribuidos, puedes entender por qué Postgres es de un solo nodo
Piensa qué es más importante que el rendimiento
Comentarios en Hacker News
TigerBeetle es excelente, pero vale la pena notar que este artículo fue escrito por una firma de inversión que invirtió en TigerBeetle enlace relacionado
Durante los próximos meses seguirán saliendo posts como este que yo escribí; ojalá la gente los discuta más activamente. Me pregunto si sería mejor agregar un descargo al inicio; no es difícil hacerlo
El artículo está claramente publicado en el sitio de la firma de inversión como “Portfolio Spotlight”, así que hay que ajustar las expectativas
No voy a comentar demasiado sobre la forma en que está escrito, pero se nota muy fácilmente cuando un texto viene de una firma de inversión
Soy fan de la búsqueda de corrección de TigerBeetle, de sus prácticas de programación y de su dirección hiperespecializada, pero quiero criticar algunos puntos del post
La explicación sobre multinodo es algo engañosa. Digan lo que digan los de cloud native, con una sola DB bien ajustada y un connection pooler se puede manejar una cantidad enorme de QPS. En una empresa anterior, durante mantenimiento, por error mandamos todo el tráfico a una sola instancia MySQL 8 en RDS, y aun así aguantó 80~90K QPS sin problema. La instancia ni siquiera era grande; solo teníamos bien ajustados el esquema, las queries y ProxySQL/MySQL. En horas pico, con un writer y dos read replicas, también manejábamos tranquilamente 120K QPS
Si usas NVMe local al nodo en el servidor, es muy probable que antes pegues con el límite de CPU
Sobre redundancia, cualquier RDBMS diseñado para entornos de red termina teniendo failover y hot standby
El sistema de consenso de TigerBeetle es ingenioso y no tiene dependencias externas, pero no intenta manejar filas grandes. Si procesas miles de transacciones por paquete de 1MiB, puede lograr cosas que serían imposibles en un RDBMS tradicional
Estas críticas no buscan minimizar sus logros; sigo muy impresionado con este producto
Justamente señalar el límite del protocolo de consenso es el punto clave. TigerBeetle busca separar y manejar únicamente cargas de trabajo transaccionales, no reemplazar todas las db OLGP. La idea es mover solo los datos importantes a una DB transaccional aparte. Algo parecido también se ve en TurboPuffer
Es cierto que los RDBMS modernos son suficientemente rápidos, pero el caso de uso de TigerBeetle es un entorno especial de alta contención. De hecho, ya demostraron en pruebas reales que cuando varias transacciones tocan una misma cuenta, el rendimiento total del clúster cae drásticamente. (Referencia: comentario relacionado en HN)
Me gusta muchísimo el trabajo de Joran y el equipo sobre DST, conciencia de sistemas distribuidos y pruebas de rendimiento; en particular, su obsesión por minimizar dependencias es impresionante (aunque supongo que también podría considerarse al SO como una dependencia)
Pero siempre siento que su forma de tratar el OLTP general (que el equipo llama OLGP) es algo injusta. Por ejemplo, comparan usando como caso solo transacciones SQL lentas, como si en transacciones financieras solo se usara bloqueo por fila, y lo presentan como si se siguieran usando enfoques de diseño OLTP de hace 50 años
En la página oficial de rendimiento, la contención solo puede bajarse hasta 1%. No creo que en un lugar como Stripe hablen de 1% de contención en su DB OLTP
Sí se puede construir un sistema que prediga la contención, la maneje de forma elegante y logre un rendimiento transaccional extremo. Esos sistemas protegen a la DB de la contención para que pueda seguir escalando. De hecho, las cifras de rendimiento de sistemas de pagos a gran escala son mucho mayores que las comparaciones oficiales de rendimiento
El marketing ignora sobre todo estos puntos y trata el tema como si todos los desarrolladores simplemente lanzaran transacciones mal hechas, cuando en realidad la mayoría son ingenieros mucho más listos. En la industria de pagos incluso existe el rol de 'payments engineer'
TigerBeetle es increíble, pero me incomoda ese patrón de marketing que lleva a malinterpretar otros sistemas OLTP
Gracias por los elogios
Dijiste que en la DB OLTP de Stripe no hay 1% de contención, pero Stripe está basado en MongoDB. Compararlo con un RDBMS es comparar peras con manzanas
Sobre si el SO subyacente puede considerarse una dependencia: he trabajado con sistemas que corrían totalmente in-memory y persistían incluso durante
kexec. En situaciones donde ni siquiera puedes hacer syscalls, el SO claramente también puede ser una dependenciaMe gustaría ver un ejemplo de una optimización que use chequeos de condición al momento del commit en vez de transacciones basadas en locks
Consideramos TigerBeetle, pero tuvimos obstáculos como estos
Usamos Cloudflare Workers y la app cliente de TigerBeetle no está soportada. enlace al issue Tal vez funcionaría en Cloudflare Containers, pero nuestro flujo de trabajo está centrado en Workers
No tiene funcionalidad de autenticación (
auth). En servidores como VPS solo puedes restringir por IP, pero en entornos serverless no hay IP fija issue relacionadoUna solución también podría ser usar Wireguard para autenticar IPs mediante llaves ECC
En la práctica, si en Cloudflare Workers o AWS Lambda mil workers abren conexiones al DB al mismo tiempo, eso causa problemas. Por eso normalmente se resuelve poniendo un proxy o una capa de servicio delante del DB. Como el proxy sabe cómo acceder al DB, no se preocupa por el problema de auth dentro de una red privada
Si hablas con el equipo de soluciones de TigerBeetle, podrían proponerte una solución personalizada, como autenticación a nivel lógico mediante cifrado end-to-end
Cuesta creer que en 2025 exista una DB sin autenticación. Si es una DB financiera, al menos deberían publicar en su sitio una guía para agregar un proxy o capa de autenticación. Si no usa HTTP (algo que no queda claro solo por la documentación), todo el mundo se preguntará cómo poner un proxy de autenticación sin HTTP. Exponer eso a internet en ese estado sería muy peligroso
Había una pregunta: “En 10 años el volumen de transacciones aumentó más de 1000 veces y la DB que usamos es SQL de hace 20-30 años. ¿Podrá aguantar?” Yo creo que sí, perfectamente.
Aunque sea software de hace 30 años, ha seguido actualizándose y además fue construido sobre bases robustas desde el principio
Soy Joran (TigerBeetle). En cargas generales no hay problema, pero en procesamiento transaccional aparecen problemas con los row locks de SQL por la contención de tipo power law (ver la ley de Amdahl). En el sitio tenemos una contention calculator donde se puede calcular el límite máximo teórico de rendimiento; échale un vistazo contetion calculator
Basta ver que DNS, publicado en 1983, sigue siendo la base de internet. Si los fundamentos están bien hechos, un sistema de más de 30 años puede aguantar perfectamente. SQL es suficientemente bueno para la mayoría de las cargas
No siempre la tecnología nueva y elegante va a ser mejor que la tecnología probada, usada y validada durante años. A veces siento que los ingenieros de software son los ingenieros con peor 'memoria' de toda la industria
Cuando manejas decenas de DB en un sistema distribuido, las transacciones distribuidas (Sagas, etc.) sí son imprescindibles. Pero en un escenario de una sola máquina, una DB relacional sigue siendo excelente
En el hardware antiguo faltaba rendimiento, pero ahora la tecnología avanzó y más bien corre mejor y más rápido
FoundationDB también comparte bastante con la discusión alrededor de TigerBeetle
Escritura de código lenta, DST, sin dependencias, entorno distribuido por defecto en producción, tolerancia a desajustes de reloj con locking optimista, pruebas durísimas de Jepsen, pruebas en un lenguaje nuevo (Flow), etc. Con FDB también se pueden resolver prácticamente los mismos problemas, y creo que TigerBeetle está más optimizado para su caso de uso
La única razón por la que FDB no es popular es que no hay muchas capas bien hechas sobre él. Aun así, algunas personas están desarrollando por su cuenta capas de SQS, DynamoDB y SQLite
La verdadera razón por la que FDB no es popular es Apple. Salió en 2013, el producto gustó tanto que compraron la empresa y a todos los usuarios existentes les cortaron el servicio. Incluso después de terminar la exclusividad, la confianza no se recuperó
Estamos preparando también un post sobre DST en colaboración con el equipo de FDB
Sí me da curiosidad qué pasó después de la adquisición
Literalmente creo que es 'the one true database'
Me pregunté “¿por qué ningún hyperscaler usa FDB?” y al buscar en GitHub resultó que terminó bajo Apple
Hace poco intenté aplicar el estilo de desarrollo de TigerBeetle a Rust, Go, etc., y de verdad lo recomiendo muchísimo
Un solo punto de entrada, casi cero dependencias
CI local, ejecutar pruebas/cobertura/lint, etc. con un solo comando
Me hizo interesarme en introducir simulación con pruebas property/snapshot/swarm
Separación entre rápido/lento, y todas las pruebas usan seed de forma determinista
Upper bounds explícitos + manejo de pools de recursos; incluso la asignación dinámica de memoria se vuelve más fácil de entender en el código
Todo gracias a los videos y la documentación del equipo de TB
Me impresionó la parte de “tener assertions activadas en producción”
Nunca entendí por qué se desactivaban las assertions. Si una assert falla en producción, deberías enterarte de inmediato (hablo en sentido retórico)
Históricamente, desactivar assertions sí daba mejoras de rendimiento. Pero hoy en día, unas cuantas comparaciones extra no cambian mucho
Originalmente, las assertions son checks para evitar mal uso de la API por parte de desarrolladores. En la etapa de entrada del usuario, es más razonable convertir eso en lógica de negocio con mensajes de error adecuados
A veces quieres usar assertions también para cosas que no son fáciles de verificar. Por ejemplo, comprobar que una lista esté ordenada
El propósito original de las assertions era revisar en tiempo de compilación/pruebas. Si quieres usar eso en prod, puedes cambiarlo por un
if. Hay que pensar siassertno es más que azúcar sintáctica convenienteMe gustaría que el equipo de TB difundiera más ampliamente el modelo double-entry más allá de finanzas. También es muy útil en escenarios como acciones, boletos para eventos, etc. Ya terminaron de mejorar la API; ahora toca mostrar cómo usarlo
Como analista uso mucho SQL, pero no soy desarrollador de código. En general entiendo la explicación de alto nivel y las ventajas de rendimiento. Tengo algunas dudas a) ¿Cómo se ven realmente las estructuras de datos de TigerBeetle? No creo que sean tablas normales b) Si no puedes usar queries SQL, ¿cómo se usa entonces? c) ¿Cómo se aplicaría el modelo double-entry a acciones, boletos, etc.? Por ejemplo, si un recinto tiene 1000 boletos y vende uno, ¿se pasa del inventario a efectivo, y de ingresos diferidos a obligación de cumplimiento? ¿O antes de vender el boleto no existe ninguna entrada?
En Postgres también se puede implementar algo parecido a double-entry
La frase “la mayoría de los equipos escriben código rápido, sufren con las pruebas y acumulan dependencias” en realidad era más bien el estándar hace 25 años. Antes de que Google y Facebook introdujeran la cultura de “move fast and break things”, todo el mundo desarrollaba con extrema lentitud, probaba bien y avanzaba con cuidado. Ojalá TigerBeetle reciba más reconocimiento. También vale la pena leer el reporte de Jepsen Jepsen report
Habrá que esperar 25 años y ver si TigerBeetle se vuelve el próximo Google o si un producto lento pero perfecto termina devorado por un competidor más rápido
“Move fast and break things” era el lema de Facebook. Google más bien estaba obsesionado con las pruebas. Claro, también hay que ajustarse a requisitos reales, y los ingenieros muchas veces inventan demasiados requisitos hipotéticos y eso genera ineficiencia. Entregarle el producto rápido a usuarios reales y reflejar su feedback vale mucho más que pulirlo infinitamente ‘dentro de una burbuja’
Aparte del contenido del texto de arriba, el sitio web de TigerBeetle en sí también es bastante impresionante.
Da la sensación de que es algo sumamente rápido, y se nota un diseño que intenta explicarlo de una forma amena, en lugar de hacerlo ver como una tecnología pesada, así que me pareció interesante.
Enlace: https://tigerbeetle.com
Me corrijo. Viéndolo de nuevo, sí se siente algo pesado. Aun así, me pareció estéticamente impresionante, así que lo comparto :)
Tal cual. La animación es rápida, así que logra una pantalla que no se siente aburrida sin distraer de lo importante del contenido. Y además da una señal muy clara de que TigerBeetle es increíblemente rápido jaja
Muy interesante.
Parece que el tiempo de las animaciones está configurado para ser mucho más corto que en los sitios comunes. Qué interesante que también se pueda abordar de esta manera...