Tech • AI • Robotics
Build a Defect Tracker Using AWS (Serverless Project)
5/10TL;DR
A compact AWS smart-factory design replaces paper defect logs with near-real-time digital tracking, using mostly serverless components to record issues, trigger urgent email alerts, and send scheduled summary reports.
KEY POINTS
Factory-floor reporting in seconds
Workers submit defects through a simple web dashboard with two fields: severity and description. The aim is speed and low friction, so reporting can be completed in about 10 seconds, reducing the chance that operators skip logging problems during a shift.
One server, two jobs
The only server in the design is a small EC2 instance in a public subnet running Nginx to serve the dashboard. That same machine also runs the reporting schedule, giving it a dual role as both the user-facing web host and the system’s scheduler.
API Gateway as the public entry point
The browser does not connect directly to the database. Instead, it sends a POST request to API Gateway, which exposes a single REST endpoint and uses CORS so the webpage hosted on EC2 is allowed to call the API from a browser.
Lambda intake writes the official record
A first Lambda function acts as the intake layer. It creates a unique defect ID, timestamps the entry, stores it in DynamoDB, and marks the initial status as logged. The table runs in on-demand mode, keeping costs low during quiet periods while absorbing spikes without manual capacity planning.
SQS decouples fast intake from slower processing
After writing to DynamoDB, the intake function places a copy of the defect message on SQS and immediately returns a success response to the worker. This separation prevents the user from waiting on downstream logic and allows the queue to absorb bursts such as 50 defects in 1 minute, while automatically retrying failed processing attempts.
Severity workflow handled by code, not orchestration
A second Lambda function consumes messages from SQS and acts as the triage layer. It first increments CloudWatch metrics by severity, then uses a simple branch: if the defect is high or critical, it updates the DynamoDB status from logged to escalated and publishes the event to an SNS alert topic. Lower-severity defects remain stored for later review.
Urgent alerts and routine reports are kept separate
The architecture uses two SNS topics. One topic sends urgent alert emails to operational responders, while the second is reserved for routine reports, avoiding the risk that users mute a channel carrying time-sensitive incidents.
Scheduled summaries come from a third Lambda
A third Lambda function scans the defect ledger, filters for the current day, counts totals and criticals, and creates a plain-text summary. It then publishes the report through the separate SNS reporting topic so managers and other stakeholders can track quality trends without being mixed into the alert flow.
Cron replaces a managed scheduler
Instead of using EventBridge, the design relies on a single cron entry on the EC2 host to invoke the reporting Lambda through the AWS CLI. In the demonstration setup, the schedule runs every 5 minutes rather than once daily, allowing rapid validation of the reporting flow.
Lean permissions and explicit limits
The three Lambda functions share one IAM execution role limited to the table, queue, topics, and metrics they need. The EC2 instance uses a separate IAM role that can invoke Lambda and nothing else. The design is intentionally a learning build, with no login on the dashboard and broader permissions than a production security review would normally allow.
CONCLUSION
The system shows how a small set of AWS services can turn defect reporting from a delayed paper process into a near-instant operational workflow. Its main value is speed: urgent factory issues can move from the line to the right inbox within seconds while still producing structured daily reporting.
Explain this