Aegis / AWS / Reliability
In progressExploring incident ingestion under duplicate events.
A work-in-progress incident pipeline using SQS, Lambda, and a DynamoDB conditional write to correlate repeated error fingerprints.
My contribution
I implemented error normalization, fingerprinting, and conditional incident creation. The repository still needs deployment and batch-processing hardening before I would describe it as production-ready.
Current mechanism
One fingerprint, one incident record.
The handler normalizes an error type and message, hashes that string, and attempts a conditional DynamoDB write. A matching record takes the duplicate path and updates its last-seen timestamp.
The present normalization handles case and line breaks. It does not establish that differently worded errors are semantically equivalent, and the record does not yet track an occurrence count.
The next step is to make the pipeline dependable under batch delivery and partial failure, then measure it with repeatable workloads.
Evidence & limitations
What the work establishes.
The handler correlates matching fingerprints and updates last-seen time. At the reviewed revision it reads only the first SQS record. The template does not provision the DynamoDB table, its access permissions, or a dead-letter queue. These are unresolved implementation limits.
What I would validate next
- 01Process every record and report individual batch failures.
- 02Make the stack reproducible, including the table, scoped permissions, and dead-letter handling.
- 03Test duplicate deliveries, malformed payloads, and downstream failures before load testing.