Propósito

Esta página organiza la solución por etapas y por servicios para explicar el runtime final sin mezclar presentación ejecutiva, decisiones arquitectónicas, validación y código en un único texto largo. La intención es que un revisor técnico pueda recorrer la implementación real desde el contexto general hasta cada componente desplegado en AWS.

Audiencia principal:

• entrevistador técnico
• revisor de arquitectura
• persona que quiera recorrer el repo y entender por qué existe cada servicio

Cómo leer esta documentación

1. Empezar por la visión general del desafío y la secuencia real de evolución.
2. Bajar a infraestructura y entrada del flujo.
3. Seguir con desacople, orden y orquestación.
4. Cerrar con la llamada HTTP, la validación operativa y la evidencia en AWS.

Estado real documentado

• Arquitectura final desplegada: 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).
• Validación funcional limpia: 100/100 registros cerrados.
• Validación de carga: 10,000/10,000 registros cerrados en un solo slot.
• Estado residual: hardening operativo y profundización documental, no bloqueo de arquitectura base.

Relación con specs y roadmap

La secuencia real del repo sigue el roadmap spec-driven de specs/roadmap/phased-spec-driven-plan.md:

• auditoría y diagnóstico
• núcleo funcional end-to-end