Filedrop

// how a request flows through it

1. The browser hits POST /uploads with a filename + email. A Lambda validates the input, writes an AWAITING_UPLOAD row to DynamoDB with a 48h TTL, and returns a 15-minute presigned S3 PUT URL.
2. The browser PUTs the file bytes directly to S3 using that URL. No server in the middle, no bytes touched by Lambda.
3. S3 fires an Object Created event to EventBridge. A rule matches the uploads/ prefix and invokes the process Lambda.
4. process HEADs the object, re-checks size + extension, and does a conditional DynamoDB update — SET status = UPLOADED IF status = AWAITING_UPLOAD. That condition is the idempotency gate: duplicate S3 deliveries fail it and are dropped silently.
5. process publishes to SNS filedrop-events. Two SQS queues fan out: notify-queue (filter: event_type = file_uploaded) drives the notify Lambda; audit-queue catches everything and appends to a separate audit table.
6. The notify Lambda signs a fresh 24-hour GET URL and hands it to SES, which emails the download link to the address on the upload.

Read the full architecture — with diagrams, IAM breakdown, and failure modes →