Use EventBridge Scheduler for one-time delivery
EventBridge Scheduler handles the requested delivery time, and automatic deletion removes completed one-time schedules without manual cleanup.
CASE STUDY / 03 OF 03
AWS Serverless Messaging Lab.
A deployed serverless prototype showing how to handle immediate and scheduled email requests through separate workflows.
PROJECT EVIDENCE
Available to review.
Two public paths
The deployed page provides distinct forms for immediate requests and one-time scheduled notifications.
Service handoffs
The public architecture explanation maps API Gateway, Lambda, SNS, EventBridge Scheduler, IAM, and CloudWatch Logs to their workflow responsibilities.
Prototype boundary
The site identifies the implementation as an educational prototype rather than a production customer messaging service.
Project context
The AWS Serverless Messaging Lab models two common notification needs: sending an email after a form request and scheduling one for a later time. It is an educational prototype that demonstrates the workflow and service handoffs, rather than a production messaging service.
The problem
Immediate requests and scheduled messages follow different timing and operational paths. A usable design must validate requests, restrict service permissions, and leave enough execution detail to investigate failures.
Operating constraints
- An email recipient must confirm the Amazon SNS subscription before delivery.
- Each function needs permissions limited to its assigned workflow.
- The scheduling form must keep requests within a defined Asia/Manila delivery window.
Approach and solution
Delivery approach
I separated immediate submission from one-time scheduling so each request follows the path appropriate to its timing. Both paths validate input, use scoped permissions, and expose execution logs for troubleshooting.
Technical solution
The frontend uses Next.js 15 App Router, React, TypeScript, and Tailwind CSS 4, hosted on AWS Amplify. Amazon API Gateway HTTP API passes requests to Python-based AWS Lambda functions. Amazon SNS handles confirmed email subscriptions and delivery; Amazon EventBridge Scheduler triggers future requests. AWS IAM limits permissions, and Amazon CloudWatch Logs records execution details.
My contribution
I designed and deployed both request paths, including form validation, API integration, Lambda functions, SNS publishing, EventBridge schedules, IAM policies, and monitoring.
Team ownership
This is an independent learning prototype. Its public page explains the architecture and provides the forms; it does not represent a production customer messaging service.
Key decisions
Scope IAM permissions to each messaging path
The immediate path only needs to publish to SNS; the scheduled path also needs to create a schedule. Separate permissions make each function's responsibility clearer and reduce unnecessary access.
Tools & technology
- Next.js 15 (App Router)
- React
- TypeScript
- Tailwind CSS 4
- AWS Amplify Hosting
- Amazon API Gateway HTTP API
- AWS Lambda (Python runtime)
- Amazon SNS (Standard topic)
- Amazon EventBridge Scheduler
- Amazon CloudWatch Logs
- AWS IAM (least-privilege policies)
Current result
The deployed prototype presents separate immediate and scheduled request forms and explains the role of each managed service. The public page identifies the system as a learning prototype.
Next improvement
Publish redacted execution traces for both paths and add automated tests for request validation and scheduling edge cases.
Lessons for future work
- Assigning a clear responsibility to each managed service makes the workflow easier to explain and troubleshoot.
- Permission boundaries, validation, and logs must be designed with the request paths, rather than added after deployment.
This prototype addresses two notification timing needs with separate request paths. It is deployed in the ap-southeast-1 Region, and the public page documents SNS subscription confirmation, EventBridge scheduling, Python-based Lambda functions, IAM roles, and CloudWatch Logs.