Firmar un documento es una operación de milisegundos. Firmar cuarenta mil, el último día del mes, mientras el mismo sistema atiende a los usuarios en línea, es un problema de arquitectura. Y es el punto donde muchos proyectos de firma electrónica que funcionaban perfecto en pruebas se caen en producción.
Este artículo describe cómo se diseña un procesamiento de firma por lotes que aguante los picos: qué sacar del ciclo de la petición web, cómo evitar duplicados, dónde está el cuello de botella real y qué métricas mirar cuando algo va mal.
Por qué la firma no puede ser síncrona
La tentación inicial es exponer un endpoint que reciba el documento, lo firme y devuelva el resultado. Funciona hasta el primer lote grande, y entonces aparecen los tres problemas de siempre: la petición supera el tiempo máximo del servidor web, el cliente reintenta y genera trabajo duplicado, y un proveedor externo lento —el servicio de sellado o el de revocación— deja peticiones colgadas consumiendo hilos.
El patrón correcto es de recepción y confirmación diferida: la aplicación recibe la solicitud, la valida mínimamente, la deja en cola y responde de inmediato con un identificador de trabajo. El cliente consulta después el estado, o —mejor— recibe un aviso cuando el trabajo termina. Ese aviso es un caso de manual para webhooks de notificación automática: el sistema receptor no consulta cada segundo, se entera cuando hay novedad.
Anatomía del pipeline
Un flujo de firma masiva bien separado tiene etapas independientes, cada una con su propia cola y su propia política de reintento:
- Ingesta: se recibe la solicitud, se persiste y se devuelve un identificador.
- Preparación: se genera o se recupera el documento y se valida su estructura. Los errores de datos se detectan aquí, antes de gastar una operación criptográfica.
- Firma: la operación con la clave. Es la etapa con el recurso escaso.
- Sellado y validación: sello de tiempo e información de revocación, si el nivel lo exige. Depende de servicios externos, así que va aparte.
- Almacenamiento: el documento firmado va al repositorio definitivo con su registro de auditoría.
- Entrega y notificación: envío al destinatario y aviso al sistema de origen.
La ventaja de separarlas es que un fallo en la etapa cuatro no obliga a repetir la uno, y que cada etapa se escala por separado. Si el sellado va lento, se le agregan trabajadores sin tocar el resto.
Idempotencia: la regla que evita duplicar
En un sistema con reintentos, el mismo mensaje se procesará dos veces alguna vez. No es una posibilidad remota: es una certeza estadística. Si eso produce dos facturas con secuenciales distintos para la misma venta, el problema deja de ser técnico y pasa a ser tributario.
La defensa es una clave de idempotencia por unidad de trabajo, generada por el sistema de origen y persistida antes de procesar. Antes de firmar, el trabajador comprueba si ya existe un resultado para esa clave y, si existe, lo devuelve sin volver a firmar.
Dos precisiones que suelen faltar:
- La clave debe reflejar el documento lógico, no el intento. Si se genera nueva en cada reintento, no sirve de nada.
- La comprobación y el registro del resultado tienen que ser atómicos. Dos trabajadores tomando el mismo mensaje a la vez es exactamente el escenario que hay que cubrir, y solo se resuelve con una restricción de unicidad en el almacenamiento.
Concurrencia: dónde está el cuello de botella real
El límite casi nunca es la CPU. Es el acceso a la clave privada, y depende de dónde esté:
| Custodia de la clave | Paralelismo posible | Diseño de trabajadores |
|---|---|---|
| Token USB | Una operación a la vez | Un solo trabajador serializado por dispositivo |
| Archivo .p12 en memoria | Alto | Varios trabajadores, límite por CPU y por E/S |
| Módulo de hardware | Alto, según el equipo | Pool de sesiones dimensionado al dispositivo |
| Firma en la nube | Alto, con límites del servicio | Concurrencia acotada al límite contratado |
Un token USB es el caso más restrictivo y hay que asumirlo desde el diseño: la interfaz del dispositivo es secuencial, como se explica en PKCS#11 para tokens y HSM. Poner veinte trabajadores contra un solo token no acelera nada y suele producir errores intermitentes difíciles de diagnosticar.
Con archivo .p12 el paralelismo es real, siempre que la clave se cargue una vez en memoria y no se lea del disco por documento; las precauciones de custodia están en firmar en servidor con .p12.
Reintentos: distinguir lo transitorio de lo permanente
Reintentar todo por igual es una forma eficaz de multiplicar un incidente. La clasificación mínima:
| Tipo de error | Ejemplos | Acción |
|---|---|---|
| Transitorio | Tiempo agotado del servicio de sellado, caída de red, bloqueo temporal | Reintentar con espera creciente y tope |
| Permanente de datos | Documento mal formado, campos obligatorios ausentes | No reintentar; a la cola de errores para corrección |
| Permanente de credencial | Certificado vencido o revocado, PIN incorrecto | Detener el flujo completo y alertar |
| De negocio | Secuencial duplicado, referencia inexistente | Devolver al sistema de origen |
El tercer caso merece énfasis: si el certificado venció, reintentar cada documento del lote genera miles de fallos idénticos y ruido que oculta el problema real. La comprobación de vigencia debe hacerse al iniciar el lote, no por documento, y detener todo si falla. El mecanismo de consulta está en validación OCSP y CRL en tiempo real.
Y una cola de errores definitivos es imprescindible. Sin ella, los mensajes irrecuperables circulan para siempre consumiendo capacidad.
Picos, prioridades y contrapresión
El cierre de mes no se distribuye: llega concentrado. Tres mecanismos que funcionan:
- Colas separadas por prioridad. Lo interactivo —un usuario esperando frente a la pantalla— no debe competir con un lote de veinte mil documentos programado.
- Contrapresión hacia el origen. Si la cola crece más allá de un umbral, el sistema debe rechazar o diferir nuevas solicitudes explícitamente, en vez de aceptar trabajo que no podrá procesar.
- Lotes con tamaño acotado. Trocear un envío de cincuenta mil documentos en bloques permite reintentar el bloque fallido sin repetir todo.
Sobre el escalado automático hay una advertencia importante: agregar trabajadores no ayuda si el recurso escaso es el dispositivo de firma o el límite del servicio de sellado. Antes de escalar, mide dónde se acumula la espera. Un patrón útil es agrupar por certificado, para que todos los documentos que usan la misma clave se procesen en el mismo trabajador y no compitan entre sí.
Qué medir
- Profundidad de cada cola y su tendencia. Una cola que crece de forma sostenida es un aviso con horas de anticipación.
- Tiempo de extremo a extremo, desde la recepción hasta el documento entregado, no solo la duración de la firma.
- Tasa de error por tipo, con la clasificación anterior. Un cambio en la proporción indica un problema nuevo.
- Latencia de los servicios externos de sellado y revocación, que suelen ser el primer síntoma de degradación.
- Antigüedad del mensaje más viejo en cada cola: la métrica que mejor refleja lo que percibe el usuario.
- Días restantes de vigencia del certificado como métrica permanente, con alerta anticipada.
El caso de la facturación
El escenario de firma masiva más común en Ecuador es la emisión de comprobantes electrónicos, y agrega su propia complejidad: además de firmar hay que enviar al SRI, esperar la respuesta de recepción y consultar la autorización, todo con sus propios estados y reintentos. Es un pipeline de varias etapas más largo, con reglas de negocio en cada punto. La parte de firma está en XAdES para comprobantes del SRI y el diseño de la integración en la API de firma para facturación masiva.
Si el objetivo es facturar y no construir infraestructura, el grupo también ofrece Azur, sistema de facturación electrónica autorizado por el SRI que resuelve la firma, el envío, la autorización y la entrega sin que tu equipo tenga que sostener colas ni reintentos. Puedes crear una cuenta en azur.com.ec/registro.
Para el certificado del firmante, la emisión es 100% en línea y toma aproximadamente 30 minutos, en archivo .p12, token USB o firma en la nube. Los valores por volumen están en la página de precios.
Omnifox cuando el lote falla
El grupo desarrolla además Omnifox, plataforma omnicanal que reúne WhatsApp, correo, redes y llamadas en una sola bandeja compartida. Cuando un lote se atrasa, quien recibe el reclamo no es el equipo de infraestructura sino atención al cliente; tener esas conversaciones en una bandeja con historial por cuenta y asignación por responsable permite responder con contexto en lugar de reenviar el problema. Más información en omnifox.io.
Preguntas frecuentes
¿Cuántos documentos por hora se pueden firmar?
Depende por completo de dónde esté la clave y del nivel de firma elegido. Un lote con sello de tiempo por documento va a un ritmo muy distinto de uno con firma básica. La única cifra confiable es la que salga de medir tu propio flujo con el hardware real.
¿Conviene firmar en el momento o de forma diferida?
Diferida en casi todos los casos de volumen. La firma inmediata tiene sentido cuando un usuario espera el resultado en pantalla, y aun así conviene que el sellado y la entrega ocurran después.
¿Qué pasa si el proceso se cae a mitad del lote?
Con estados persistidos por documento y claves de idempotencia, se retoma donde quedó sin duplicar. Sin eso, la única salida segura es una conciliación manual, que es exactamente lo que hay que evitar.
¿Puedo firmar varios documentos con una sola operación?
Cada documento necesita su propia firma. Lo que sí se optimiza es el acceso a la clave: abrir la sesión una vez y firmar en serie es mucho más rápido que abrir y cerrar por documento.
¿Hace falta una cola dedicada solo a la firma?
Separar la etapa de firma en su propia cola es lo que permite controlar la concurrencia contra el recurso escaso sin frenar el resto del pipeline. Es la separación que más rendimiento aporta con menos esfuerzo.
Si tu operación firma miles de documentos al mes y necesita certificados dimensionados para ese volumen, conversa con un asesor corporativo de Firmas.com.ec. Cotiza tu plan corporativo.