Next question. The spec describes a production-grade circuit breaker for PAI-EAS fallback:
A dedicated health check Lambda that pings PAI-EAS every 60 seconds
A CloudWatch alarm that watches P99 latency and error rate
A classifier_flag written to DynamoDB when conditions breach
Every SQS consumer Lambda reads that flag before each message
This is the right pattern for production, but for a 24-hour hackathon it means you're building and wiring a third Lambda, a CloudWatch alarm, and a DynamoDB read on every inference call — before you've even shipped the core flow.
The simpler alternative: the consumer Lambda catches PAI-EAS exceptions inline and falls back to the keyword classifier in the same execution. Same result (graceful degradation), zero extra infrastructure.
Do you want to keep the CloudWatch alarm + DynamoDB flag circuit breaker, or simplify to an inline try/catch fallback in the Lambda?
Next question. The spec describes a production-grade circuit breaker for PAI-EAS fallback:
A dedicated health check Lambda that pings PAI-EAS every 60 seconds
A CloudWatch alarm that watches P99 latency and error rate
A classifier_flag written to DynamoDB when conditions breach
Every SQS consumer Lambda reads that flag before each message
This is the right pattern for production, but for a 24-hour hackathon it means you're building and wiring a third Lambda, a CloudWatch alarm, and a DynamoDB read on every inference call — before you've even shipped the core flow.
The simpler alternative: the consumer Lambda catches PAI-EAS exceptions inline and falls back to the keyword classifier in the same execution. Same result (graceful degradation), zero extra infrastructure.
Do you want to keep the CloudWatch alarm + DynamoDB flag circuit breaker, or simplify to an inline try/catch fallback in the Lambda?