El autor de Nosdesk, una plataforma de soporte al cliente, detalla en un artículo técnico la arquitectura de su backend, escrito por completo en Rust y compuesto por unas 120.000 líneas de código repartidas en 260 módulos, con alrededor de 1.030 tests. El sistema se distribuye como un único binario desplegado con un solo docker compose up y se apoya en una pila deliberadamente reducida: Actix-web como capa HTTP, Diesel sobre Postgres para persistencia, Redis para distribución de mensajes y Tokio como runtime asíncrono.
El texto describe tres hábitos que guiaron el desarrollo: empujar los errores peligrosos al sistema de tipos, separar la lógica pura de las operaciones de entrada/salida y escribir comentarios que expliquen el porqué, no el qué. A partir de ahí, repasa los componentes clave: la sincronización inicial del cliente, que se sirve como un stream de JSON delimitado por saltos de línea a través de un canal mpsc con back-pressure para evitar picos de memoria; un motor de sincronización basado en un log append-only llamado sync_actions, del que leen tres consumidores independientes (sincronización HTTP, canal push en vivo y registro de auditoría); y un bus de difusión sobre Server-Sent Events que combina un tokio::sync::broadcast con un anillo de eventos recientes para permitir reconexiones sin resincronización completa.
El artículo aborda también la edición colaborativa en tiempo real, implementada con CRDT mediante el puerto en Rust de Yjs (yrs) e integrada como actores de Actix, y el subsistema de correo electrónico, de unas 14.000 líneas, diseñado con un circuit breaker de estado abierto/cerrado/semiabierto, backoff con jitter completo y entrega al menos una vez con leasing mediante FOR UPDATE SKIP LOCKED.