$FOGO for una razón que no tiene nada que ver con los números de la tabla de clasificación, y todo que ver con cómo la cadena presiona silenciosamente a los constructores para que maduren en su arquitectura, porque cuando construyes en un L1 basado en SVM no solo estás eligiendo un entorno más rápido, estás eligiendo un modelo de ejecución que recompensa un buen diseño de estado y expone un mal diseño de estado sin piedad.
Fogo se siente como si estuviera siendo moldeado en torno a la idea de que la velocidad no debería ser una afirmación cosmética, porque si los bloques son genuinamente rápidos y el tiempo de ejecución puede procesar trabajo independiente al mismo tiempo, entonces la aplicación se convierte en el verdadero cuello de botella, y ese cambio es donde la historia de SVM se vuelve interesante, ya que el tiempo de ejecución básicamente le está haciendo la misma pregunta a cada desarrollador en el momento en que llegan los usuarios reales, que es si sus transacciones son realmente independientes o si accidentalmente diseñaron un bloqueo compartido que todos deben tocar.
La ejecución paralela suena simple cuando se explica como transacciones que se ejecutan juntas, pero el detalle práctico que cambia todo es que solo funciona cuando dos transacciones no pelean por el mismo estado, y en SVM el estado no es un blob invisible que la cadena interpreta como quiere, el estado es explícito y concreto, y cada transacción tiene que declarar qué leerá y qué escribirá, lo que significa que la cadena puede programar el trabajo con confianza cuando esas declaraciones no se superponen, y también significa que la cadena no puede salvarte de tu propio diseño cuando obligas a todo a superponerse.
Esta es la parte que la mayoría de los comentarios superficiales pasan por alto, porque la gente habla como si el rendimiento residiera en la capa de cadena, pero en Fogo, en el momento en que comienzas a modelar una aplicación, el rendimiento se convierte en algo que diseñas en la forma en que las cuentas y los datos están separados, y es por eso que dos aplicaciones en la misma cadena pueden sentirse completamente diferentes bajo estrés, con una manteniéndose suave mientras la otra se queda extrañamente atascada, incluso aunque ambas estén en el mismo entorno de ejecución rápida.
He notado que cuando los constructores vienen de hábitos de ejecución secuencial, llevan un instinto que se siente seguro pero se vuelve costoso en SVM, que es el instinto de mantener un objeto de estado central que cada acción actualiza, porque hace que razonar sobre el sistema se sienta limpio, hace que la analítica sea fácil, y hace que el código se sienta como si tuviera una única fuente de verdad, pero en una cadena SVM ese mismo diseño se convierte en un estrangulador silencioso, porque cada acción de usuario ahora está tratando de escribir en el mismo lugar, así que incluso si el tiempo de ejecución está listo para ejecutar en paralelo, tu aplicación ha creado un único carril en el que todo debe entrar.
Lo que cambia en @Fogo Official es que el diseño del estado deja de ser solo almacenamiento y comienza a ser política de concurrencia, porque cada cuenta escribible se convierte en una especie de bloqueo, y cuando pones demasiado detrás de un bloqueo, no solo ralentizas un pequeño componente, colapsas el paralelismo para todo el flujo, y la cadena no necesita estar congestionada para que lo sientas, porque tu propio diseño de contrato está generando la congestión al forzar a usuarios no relacionados a chocar en el mismo conjunto de escritura.
La forma más útil de pensar en ello es tratar cada pieza escribible de estado como una decisión sobre quién puede proceder al mismo tiempo, y el objetivo de diseño se convierte en reducir colisiones innecesarias, lo que no significa eliminar el estado compartido por completo, porque algún estado compartido es esencial, pero significa ser disciplinado sobre lo que debe ser compartido y lo que solo se compartió por conveniencia, porque la conveniencia es donde la ejecución paralela muere silenciosamente.
En Fogo, los patrones que mantienen a las aplicaciones sintiéndose rápidas son raramente complicados, pero son estrictos, porque requieren que un desarrollador separe el estado del usuario de manera agresiva, para aislar el estado específico del mercado en lugar de empujar todo a través de un único objeto de protocolo global, y para dejar de escribir en cuentas compartidas que están ahí principalmente para seguimiento y visibilidad, ya que esas métricas derivadas pueden existir sin convertirse en parte del camino crítico de escritura para cada transacción.
Cuando miro diseños exitosos amigables con la paralelización, tienden a tratar las acciones del usuario como mayormente locales, donde un usuario toca su propio estado y una pequeña porción de estado compartido que es verdaderamente necesaria, y la porción compartida está estructurada de una manera que no obliga a usuarios no relacionados a competir, por lo que la separación por usuario no es solo un truco de organización ordenado, es una estrategia de rendimiento, y la separación por mercado no es solo una elección de arquitectura limpia, es la diferencia entre un mercado activo que arrastra todo hacia abajo y múltiples mercados fluyendo independientemente.
La trampa oculta es que los desarrolladores a menudo escriben estado compartido porque quieren una verdad global instantánea, como totales de tarifas globales, contadores de volumen globales, rastreadores de actividad globales, tablas de clasificación globales, o métricas de protocolo globales, y el problema no es que esas métricas sean malas, el problema es que cuando las actualizas en la misma transacción que cada acción de usuario, inyectas una escritura compartida en cada camino, así que cada camino ahora entra en conflicto, y de repente has construido una aplicación secuencial dentro de un tiempo de ejecución paralelo, y no importa cuán rápida sea Fogo, porque tu propio diseño está obligando a la cadena a tratar el trabajo independiente como trabajo dependiente.
Lo que cambia la ejecución paralela, en un sentido muy práctico, es que los constructores son empujados a separar el estado de corrección del estado de reporte, y son empujados a actualizar el estado de reporte en un ritmo diferente, o a escribirlo en segmentos fragmentados, o a derivarlo de rastros de eventos, porque una vez que dejas de forzar a cada transacción a escribir en la misma cuenta de reporte, el tiempo de ejecución finalmente puede programar trabajo paralelo real, y la aplicación comienza a sentirse como si perteneciera a una cadena SVM en lugar de simplemente ejecutarse en una.
Esto se vuelve aún más visible en aplicaciones de estilo de comercio, que es donde la postura de Fogo hace que la discusión se sienta fundamentada, porque el comercio concentra actividad, y la concentración crea contención, y la contención es el enemigo de la ejecución paralela, así que si un sistema comercial está diseñado en torno a un único estado de libro de órdenes central que debe ser mutado para cada interacción, la cadena serializará esas interacciones sin importar cuán rápidas sean las bloques, y la experiencia del usuario se degradará justo cuando más importa, por lo que los constructores se ven obligados a diseñar de manera más difícil pero mejor, donde los componentes más calientes se minimizan, donde el estado se particiona, donde las rutas de liquidación se reducen, y donde las partes que no necesitan ser mutadas en cada acción se eliminan del camino crítico.
La misma lógica aparece en aplicaciones en tiempo real que la gente asume que serán fáciles en una cadena rápida, como sistemas interactivos que se actualizan con frecuencia, porque el enfoque ingenuo es mantener un único estado mundial y mutarlo constantemente, pero en @Fogo Official eso se convierte en un punto de colisión garantizado, ya que cada participante está tratando de tocar el mismo objeto escribible, por lo que el mejor enfoque es aislar el estado por participante, localizar zonas compartidas en lugar de globalizarlas, y tratar los agregados globales como algo que se actualiza de una manera más controlada, porque en el momento en que dejas de hacer que cada acción escriba en el mismo objeto compartido, el tiempo de ejecución puede comenzar a ejecutar muchas acciones juntas, y ahí es donde la velocidad percibida se vuelve real.
En la lógica de estilo alta frecuencia, que es donde las cadenas de baja latencia a menudo son juzgadas duramente, la ejecución paralela hace que los defectos de diseño sean imposibles de ocultar, porque cuando muchos actores envían acciones rápidamente, cualquier estado escribible compartido se convierte en un campo de batalla, y en lugar de construir un sistema donde muchos flujos progresan independientemente, construyes un sistema donde todos compiten por el mismo bloqueo, y el resultado no es solo una aplicación más lenta, es una dinámica de mercado diferente, porque el orden se domina por la contención en lugar de por la estrategia, que es por qué los mejores diseños tienden a aislar escrituras, reducir mutaciones compartidas y tratar los componentes en disputa como estrechos y deliberados en lugar de amplios y accidentales.
Las aplicaciones pesadas en datos muestran el mismo patrón de una manera más silenciosa, porque la mayoría de los consumidores de datos solo necesitan leer, y las lecturas no son el problema, pero cuando los flujos de consumidores comienzan a escribir datos compartidos por conveniencia, como estampar valores en cuentas globales o actualizar cachés compartidos, envenenan el paralelismo sin una verdadera ganancia, y el mejor enfoque es permitir que los consumidores lean datos compartidos y escriban solo sus propias decisiones, porque una vez que mantienes las escrituras compartidas confinadas a flujos de actualización dedicados, proteges la concurrencia para todos los demás.
La compensación que Fogo implícitamente pide a los desarrolladores que acepten es que la arquitectura amigable con la paralelización no es gratuita, porque una vez que fragmentas el estado y separas las cuentas, estás gestionando más componentes, razonando sobre más bordes, y construyendo sistemas donde la concurrencia es real en lugar de teórica, lo que significa que las pruebas tienen que ser más estrictas, las rutas de actualización tienen que ser más cuidadosas, y la observabilidad tiene que ser mejor, pero la recompensa es que la aplicación puede escalar de la manera en que se diseñó un tiempo de ejecución SVM para soportar, donde acciones independientes realmente proceden juntas en lugar de esperar detrás de un cuello de botella global.
El error que destruye la mayoría de la ventaja paralela no es un error avanzado, es uno simple, que es crear una única cuenta escribible compartida que cada transacción toca, y en una cadena como Fogo ese error es especialmente costoso, porque cuanto más rápida se vuelve la cadena, más visible es que tu propio diseño es el limitante, y esa visibilidad no es un fracaso de la cadena, es la cadena revelando lo que realmente es la arquitectura.
Fogo en este contexto hace que la conversación entre constructores sea más honesta, porque no es suficiente decir que la cadena es rápida, el modelo de la cadena obliga a un desarrollador a demostrar que merece esa velocidad, y la prueba está en la forma en que se da forma, se particiona y se accede al estado, por lo que la ejecución paralela no es un detalle de marketing, es una disciplina que cambia cómo se construyen las aplicaciones, y también es por eso que un L1 basado en SVM como Fogo no es simplemente más rápido, es más exigente, ya que pide a los desarrolladores que diseñen con el conflicto en mente, que traten el estado como una superficie de concurrencia, y que construyan sistemas que respeten la idea de que el rendimiento es tanto sobre el diseño como sobre el tiempo de ejecución.
