Serverless Event Platform
An event-processing design built around idempotency, bounded retries and recoverable failures.
Lambda · EventBridge · DynamoDB
Scope: architecture and validation design. The indicators summarize design targets. Implementation evidence will be added as the lab develops.
The scenario
A fictional order service must accept bursts without coupling the API response to downstream processing. A consumer failure must not silently lose an order or create a duplicate effect.
Architecture
The API validates requests and publishes domain events. EventBridge routes events to an SQS buffer consumed by Lambda. Conditional DynamoDB writes record an event identifier so repeated delivery can be detected. Dead-letter handling and a documented redrive procedure make failures visible.
Key decisions
The design assumes messages may be delivered more than once. Idempotency covers the business side effect, not just the handler invocation. Queue retention, timeout and concurrency limits are chosen together rather than treated as independent defaults.
Validation plan
Replay the same identifier, send an invalid payload and temporarily fail the consumer. Check duplicate suppression, dead-letter visibility, backlog recovery and alarms. Record latency and cost under a stated load profile before publishing any performance number.
Trade-offs
Asynchronous work improves decoupling but introduces eventual consistency and more operational states. A request being accepted does not mean its downstream work is finished.
Next iteration
Implement the handlers and replay harness, then document recovery behavior with sample traces. This fictional architecture has no live public API attached.
El escenario
Un servicio de pedidos ficticio debe aceptar ráfagas sin acoplar la respuesta de la API al procesamiento posterior. Un consumidor que falla no debe perder silenciosamente un pedido ni duplicar sus efectos.
Arquitectura
La API valida solicitudes y publica eventos de dominio. EventBridge los enruta a un buffer SQS consumido por Lambda. Escrituras condicionales en DynamoDB registran el identificador del evento para detectar entregas repetidas. Una cola de mensajes fallidos y un procedimiento de redrive hacen visibles los errores.
Decisiones técnicas
El diseño asume que los mensajes pueden entregarse más de una vez. La idempotencia cubre el efecto de negocio, no solo la invocación del handler. Retención, timeout y límites de concurrencia se eligen en conjunto.
Plan de validación
Repetir el mismo identificador, enviar un payload inválido y provocar un fallo temporal del consumidor. Revisar duplicados, mensajes fallidos, recuperación del backlog y alarmas. Medir latencia y costo con un perfil de carga explícito antes de publicar cifras.
Concesiones del diseño
El trabajo asíncrono reduce el acoplamiento, pero introduce consistencia eventual y más estados operativos. Aceptar una solicitud no significa haber terminado su procesamiento.
Próxima iteración
Implementar handlers y un harness de replay; después documentar la recuperación con trazas de ejemplo. Esta arquitectura ficticia no tiene una API pública activa.