Manejo de Errores en Entornos Concurrentes

Concepto clave

En sistemas de baja latencia y alta seguridad, el manejo de errores en entornos concurrentes no es solo una cuestión de corrección, sino de garantías de seguridad y predictibilidad temporal. Mientras que en aplicaciones tradicionales un error puede manejarse con logging y recuperación, en sistemas críticos un error mal gestionado puede propagarse como una falla en cascada, comprometiendo la integridad del sistema completo.

La concurrencia introduce una dimensión adicional de complejidad: los errores ya no ocurren en un flujo lineal predecible, sino que pueden emerger de interacciones no deterministas entre hilos, tareas o procesos. Imagina un sistema de control de tráfico aéreo donde múltiples controladores (hilos) actualizan simultáneamente las posiciones de aviones (datos compartidos). Un error en un hilo que no se aísla adecuadamente podría corromper los datos de otros hilos, llevando a decisiones catastróficas.

Rust aborda este desafío mediante su sistema de ownership y tipos como Result y Option, pero en contextos concurrentes debemos considerar patrones específicos: aislamiento de fallos (un error en un componente no debe afectar a otros), recuperación sin bloqueo (manejar errores sin detener todo el sistema), y señalización precisa (comunicar errores entre hilos sin pérdida de información).

Cómo funciona en la práctica

Consideremos un sistema de procesamiento de transacciones financieras donde múltiples workers concurrentes procesan órdenes de compra/venta. Cada worker debe validar, ejecutar y registrar la transacción, pero cualquier error (datos inválidos, límites excedidos, fallos de red) debe manejarse sin afectar a otros workers.

Paso 1: Definir tipos de error específicos para el dominio:

#[derive(Debug, Clone)]
enum TransactionError {
    InvalidAmount(f64),
    InsufficientFunds,
    NetworkTimeout(std::time::Duration),
    ConcurrentConflict,
}

Paso 2: Implementar procesamiento con manejo de errores aislado usando canales (mpsc):

use std::sync::mpsc;
use std::thread;

fn process_transaction_worker(
    rx: mpsc::Receiver,
    tx_error: mpsc::Sender<(Transaction, TransactionError)>,
) {
    while let Ok(transaction) = rx.recv() {
        match validate_and_execute(&transaction) {
            Ok(result) => log_success(result),
            Err(e) => {
                // Aislamiento: el error se envía a un canal dedicado
                // sin bloquear este worker
                let _ = tx_error.send((transaction, e));
            }
        }
    }
}

Paso 3: Configurar supervisión centralizada de errores:

fn error_supervisor(rx_error: mpsc::Receiver<(Transaction, TransactionError)>) {
    for (transaction, error) in rx_error {
        match error {
            TransactionError::NetworkTimeout(duration) => {
                // Reintento con backoff exponencial
                schedule_retry(transaction, duration);
            }
            TransactionError::ConcurrentConflict => {
                // Reordenamiento seguro
                requeue_with_priority(transaction);
            }
            _ => {
                // Errores fatales: alerta inmediata
                alert_operations(transaction, error);
            }
        }
    }
}

Este patrón garantiza que los errores se contengan dentro de cada worker y se manejen de forma especializada sin bloquear el procesamiento concurrente.

Caso de estudio

Sistema de matching de órdenes en un exchange de criptomonedas con latencia < 100 microsegundos y disponibilidad 99.99%. El sistema procesa 50,000 órdenes/segundo con 32 workers concurrentes.

Dato importante: En pruebas de carga, el sistema mantuvo latencia p95 < 85 microsegundos incluso con inyección de 1% de errores sintéticos, demostrando la efectividad del aislamiento de fallos.

Implementación clave del engine de matching:

struct MatchingEngine {
    order_book: Arc>,
    error_channel: mpsc::Sender,
}

impl MatchingEngine {
    fn match_order(&self, order: Order) -> Result, MatchingError> {
        let mut book = self.order_book.write()
            .map_err(|_| MatchingError::LockPoisoned)?;
        
        // Transacción lógica: si cualquier paso falla,
        // toda la operación se revierte
        let mut trades = Vec::new();
        
        match book.try_match(&order) {
            Ok(new_trades) => {
                trades = new_trades;
                book.update(&order, &trades)
                    .map_err(|e| {
                        // Rollback automático
                        book.rollback();
                        MatchingError::UpdateFailed(e)
                    })?;
                Ok(trades)
            }
            Err(e) => {
                // Error temprano: sin cambios en el libro
                Err(MatchingError::MatchingFailed(e))
            }
        }
    }
}

Errores comunes

1. Panics no controlados en hilos: Un panic en un hilo de Rust termina solo ese hilo, pero en sistemas críticos esto puede dejar recursos bloqueados o estados inconsistentes.
   Solución: Usar catch_unwind en puntos de entrada de hilos y convertir panics a Result::Err manejables.
2. Deadlocks en recovery: Intentar adquirir locks durante el manejo de errores puede crear deadlocks si otros hilos están en estados similares.
   Solución: Implementar timeouts en todas las operaciones de locking y usar lock-free data structures para rutinas de recovery.
3. Pérdida silenciosa de errores: En canales asíncronos, errores pueden perderse si el receptor no está listo o el canal tiene capacidad limitada.
   Solución: Usar canales bounded con monitoreo de capacidad y dead letter queues con persistencia.
4. Overhead excesivo de validación: Validar todo en cada operación puede aumentar la latencia por encima de los requisitos.
   Solución: Validación por capas - validaciones rápidas (checksums) en el hot path, validaciones completas en background.
5. Recuperación que empeora el problema: Reintentos automáticos sin backoff pueden crear tormentas de retries que colapsan el sistema.
   Solución: Implementar circuit breakers y backoff exponencial con jitter.

Checklist de dominio

• ¿Cada componente concurrente tiene un protocolo definido de shutdown ante errores graves?
• ¿Los errores se clasifican por criticidad (fatal, recuperable, transitorio) con estrategias distintas?
• ¿Existen métricas en tiempo real de tasa de errores por tipo y componente?
• ¿El sistema puede continuar operando (tal vez en modo degradado) ante fallos parciales?
• ¿Los mecanismos de recovery han sido probados bajo carga con inyección de fallos?
• ¿Hay documentación clara de los posibles estados de error y transiciones entre ellos?
• ¿Los timeouts son configurables y basados en SLA del sistema en lugar de valores fijos?

Implementación de un sistema de procesamiento de pagos con tolerancia a fallos

Desarrolla un sistema concurrente que procese pagos con los siguientes requisitos:

1. Crea una estructura PaymentProcessor que gestione 4 workers concurrentes
2. Cada worker debe procesar pagos recibidos por un canal MPSC
3. Implementa 3 tipos de errores específicos del dominio: InvalidCard, InsufficientBalance, NetworkFailure
4. Los errores NetworkFailure deben reintentarse automáticamente con backoff exponencial (máximo 3 intentos)
5. Los errores InvalidCard deben rechazarse inmediatamente y registrarse en un canal de errores dedicado
6. Implementa un supervisor que monitoree la tasa de errores y active un circuit breaker si supera el 5% en 10 segundos
7. El sistema debe continuar procesando pagos válidos incluso cuando el circuit breaker está activo (modo degradado)
8. Mide la latencia p95 del procesamiento exitoso y asegúrate de que sea < 2ms incluso bajo inyección de errores

Entrega el código completo con tests que simulen carga y errores, incluyendo métricas de performance.

• Usa std::sync::mpsc::channel con capacidad bounded para evitar backpressure excesivo
• Implementa el circuit breaker como una máquina de estados simple (Closed, Open, HalfOpen) usando AtomicBool
• Para las métricas de latencia, considera usar std::time::Instant y percentiles calculados sobre una ventana deslizante

Evalua tu comprension

Completa el quiz interactivo de arriba para ganar XP.