Microservicios de colas con SQLite en modo WAL y Python 3 en VPS
Cómo procesar tareas asíncronas y webhooks de comercio electrónico con cero dependencias pesadas tipo Redis usando concurrencia transaccional en SQLite.
Ficha de laminación y parámetros de impresión
La trampa de instalar Redis para 200 pedidos al día
En el diseño de sistemas web contemporáneo se asume que cualquier tarea asíncrona exige desplegar un clúster de Redis o RabbitMQ respaldado por workers en Celery. Para plataformas que procesan cientos o miles de pedidos diarios, esta arquitectura introduce costes de mantenimiento, puertos expuestos y un consumo innecesario de memoria en servidores VPS modestos.
Con frecuencia, una simple base de datos SQLite en modo WAL (Write-Ahead Logging) proporciona toda la fiabilidad transaccional requerida con cero sobrecarga operativa.
«La arquitectura más elegante no es la que presume de más servicios en Docker Compose, sino la que resuelve el problema con la menor cantidad de piezas móviles.»
El modo WAL de SQLite y concurrencia multi-proceso
Por defecto, SQLite bloquea el archivo completo durante escrituras concurrentes. Al activar PRAGMA journal_mode = WAL; y PRAGMA synchronous = NORMAL;, los lectores no bloquean a los escritores y un único escritor no interrumpe las consultas simultáneas.
En discos NVMe modernos de proveedores cloud estándar en Europa, esto se traduce en más de tres mil operaciones de encolado por segundo sin generar contención perceptible.
Patrón SKIP LOCKED simulado mediante transacciones inmediatas
Para evitar que dos workers concurrentes procesen el mismo trabajo simultáneamente, empleamos transacciones BEGIN IMMEDIATE combinadas con un identificador de worker y marca temporal de concesión (lease). Si un worker cae inesperadamente, el lease expira a los sesenta segundos y el trabajo vuelve a estar disponible para el grupo.
Monitorización de colas y rotación de bases de datos
Un pequeño script de mantenimiento ejecutado por cron cada medianoche archiva los trabajos completados en una base de datos histórica comprimida. Con esta rutina, el tamaño activo de la base de datos de colas rara vez excede los 8 megabytes, haciendo que las copias de seguridad se completen en fracciones de segundo.
