Visión general

El desafío técnico Tapi exige una arquitectura capaz de ejecutar una consulta diaria por cada registro de una tabla masiva, distribuir esa carga a lo largo del día, persistir el resultado final, distinguir errores reintentables de errores terminales y evitar por completo la concurrencia hacia un mismo proveedor.

La solución oficial documentada en esta entrega usa una topología 100% serverless en AWS, desplegada en una sola cuenta y una sola región mediante AWS CDK. El runtime implementado y validado al 2026-05-01 es:

EventBridge Scheduler (tapi-dispatch-slot-000 ... tapi-dispatch-slot-287) -> Lambda Producer (tapi-producer) -> SQS FIFO High Throughput (tapi-provider-queue.fifo) -> EventBridge Pipe (tapi-provider-pipe) -> Step Functions Express (tapi-consumer-state-machine-express) -> Lambda workflow bootstrap (tapi-workflow-bootstrap) -> Lambda Consumer (tapi-consumer) -> DynamoDB pending records (tapi-pending-records) / DynamoDB idempotency (tapi-idempotency) / DynamoDB results (tapi-results)

<aside> 📈

Alta escalabilidad

• Capacidad objetivo del problema: 1,000,000 de registros diarios, escalable a N veces.
• Distribución temporal implementada: 288 slots diarios de 5 minutos.
• Cadencia teórica objetivo para 1,000,000/día: 1,000,000 / 86,400 ≈ 11.57 RPS.
• Evidencia actual de cierre operativo:
  • Corrida 100 registros: 100/100 cerrados, 60 COMPLETED, 40 FAILED.
  • Corrida 10,000 registros: 10,000/10,000 cerrados, 5,983 COMPLETED, 4,017 FAILED. </aside>

Formulación del problema

El sistema debe resolver simultáneamente cinco restricciones operativas:

1. Procesar automáticamente una consulta diaria por cada registro.
2. Distribuir la carga durante el día para evitar ráfagas monolíticas.
3. Guardar un resultado final auditable por cada ejecución.
4. Reintentar únicamente fallos transitorios y cortar rápido los fallos terminales.
5. Garantizar tolerancia cero a la concurrencia hacia un mismo proveedor.

En términos de arquitectura, cerrado no significa exitoso: una ejecución puede cerrar correctamente como COMPLETED o como FAILED, siempre que el work item termine con persistencia final consistente en DynamoDB results (tapi-results), DynamoDB pending records (tapi-pending-records) y DynamoDB idempotency (tapi-idempotency).

Stack oficial

La entrega usa AWS CDK como infraestructura como código; EventBridge Scheduler (tapi-dispatch-slot-000 ... tapi-dispatch-slot-287) para distribuir el día en 288 disparos explícitos; Lambda Producer (tapi-producer) para consultar un único slot y publicar en SQS FIFO High Throughput (tapi-provider-queue.fifo); EventBridge Pipe (tapi-provider-pipe) para abrir Step Functions Express (tapi-consumer-state-machine-express) en modo síncrono; Lambda workflow bootstrap (tapi-workflow-bootstrap) para normalizar el input; Lambda Consumer (tapi-consumer) para encapsular la llamada HTTP al proveedor; y DynamoDB pending records (tapi-pending-records), DynamoDB idempotency (tapi-idempotency) y DynamoDB results (tapi-results) para persistencia operativa y final.

Observabilidad operativa

Para Step Functions Express (tapi-consumer-state-machine-express), la fuente oficial de auditoría operativa es CloudWatch Logs Insights sobre /aws/vendedlogs/states/tapi-consumer-state-machine. Esta entrega descarta como antipatrón de validación masiva el uso de list-executions, get-execution-history o cualquier esquema de sondeo síncrono pensado para workflows STANDARD.

Esto implica dos reglas explícitas:

• la evidencia del workflow se consulta desde CloudWatch Logs Insights
• la serialización por proveedor se demuestra desde la semántica de SQS FIFO High Throughput (tapi-provider-queue.fifo) y, cuando aplica, desde logs de /aws/lambda/tapi-consumer