DynamoDB Streams and Lambda for Real-Time Threat Detection: The Event Pipeline DynamoDB Was Built For

The architecture

Consumer scans QR > Vercel API Route > DynamoDB PutItem (SCAN# record)

                                              |

                                              v

                                    DynamoDB Stream (NEW_IMAGE)

                                              |

                                              v

                                    Lambda: authentik-threat-detector

                                      |-- Geographic anomaly check

                                      |-- Burst scan detection

                                      |-- Claim violation check

                                      |-- Hash tampering check

                                              |

                                         (if anomaly)

                                              |

                                              v

                                    DynamoDB PutItem (THREAT# alert)

                                              |

                                              v

                                    SSE endpoint polls THREAT#

                                              |

                                              v

                                    Brand dashboard updates (no refresh)

Step 1: The scan write triggers the Stream

When a consumer verifies a product, the Vercel API route writes a scan record:

const scanRecord = {

  PK: `PRODUCT#${productId}`,

  SK: `SCAN#${new Date().toISOString()}`,

  productId,

  timestamp: now,

  ip,

  country: geo.country,

  city: geo.city,

  userAgent: req.headers.get("user-agent"),

  result: hashMatch && signatureValid ? "authentic" : "suspicious",

};

await putItem(scanRecord);

This write hits DynamoDB. Because Streams is enabled with NEW_IMAGE view type, DynamoDB emits a stream record containing the complete new item. The stream record goes to a shard, and our Lambda function is subscribed to that shard.

Step 2: Lambda receives the stream event

The Lambda function is configured as a DynamoDB Stream trigger:

• 
  Batch size: 10 (process up to 10 records per invocation)


• 
  Batching window: 5 seconds (wait up to 5s to fill the batch)


• 
  Starting position: LATEST
  

export async function handler(event) {

  for (const record of event.Records) {

    if (record.eventName !== "INSERT") continue;



    const newImage = record.dynamodb.NewImage;

    const sk = newImage.SK.S;



    // Only process scan records and provenance events

    if (sk.startsWith("SCAN#")) {

      await processScan(newImage);

    } else if (sk.startsWith("EVENT#")) {

      await processEvent(newImage);

    }

  }

}

Key detail: the Lambda filters by SK prefix. Because this is a single-table design, the Stream contains writes for all entity types: brand profiles, product registrations, webhook configs. The Lambda ignores everything except SCAN# and EVENT# records. This filtering happens in application code, not at the Stream level, which means we pay for Lambda invocations on non-scan writes. At our scale, this is negligible. At very high write volume, you'd use if you want the full breakdown.)

The GSI1PK: "BRAND#brandId" projection means we can query all threats for a brand across monthly buckets with a single GSI1 query, no scatter-gather needed on the read path.

Step 5: SSE pushes to the dashboard

The final piece: getting the alert to the brand's browser without polling from the client side.

The Vercel API has an SSE (Server-Sent Events) endpoint that the dashboard connects to:

// Client (React component)

const source = new EventSource(`/api/stream?brandId=${brandId}`);

source.addEventListener("threat", (e) => {

  const threat = JSON.parse(e.data);

  setThreats(prev => [threat, ...prev]);

});

The server-side SSE endpoint queries DynamoDB every 3 seconds for new threats newer than the last timestamp:

const threats = await queryGSI1(`BRAND#${brandId}`, `THREAT#${lastTimestamp}`, {

  limit: 10,

  scanForward: true,

});

for (const threat of threats) {

  controller.enqueue(encoder.encode(`event: threat\ndata: ${JSON.stringify(threat)}\n\n`));

  lastTimestamp = threat.timestamp;

}

The total latency from scan-to-dashboard:

1. 
   PutItem scan record: ~5ms


2. 
   Stream delivery to Lambda: ~100-500ms


3. 
   Lambda anomaly checks: ~50-200ms (includes DynamoDB queries)


4. 
   PutItem threat alert: ~5ms


5. 
   SSE poll interval: up to 3s

Total: under 5 seconds from QR scan to dashboard alert.

Error handling and retry guarantees

What happens when the Lambda fails mid-execution? DynamoDB Streams has built-in retry:

• 
  At-least-once delivery: if the Lambda throws, DynamoDB retries the same batch. The function must be idempotent (writing a threat alert with the same PK/SK is a no-op PutItem, naturally idempotent).


• 
  Ordering preserved on retry: retries deliver the same records in the same order within the shard. Your anomaly detection logic sees a consistent sequence regardless of how many retries occurred.


• 
  Bisect on error: if a batch consistently fails, DynamoDB splits it in half and retries each half separately, isolating the poisoned record.

The Lambda doesn't need a dead-letter queue at our scale. If a record genuinely can't be processed after retries, it ages out of the 24-hour Stream retention window. No scan goes unprocessed silently: the scan record itself is already in DynamoDB, and the anomaly detection runs again on the next scan for the same product.

Why DynamoDB Streams (not SQS, not EventBridge)

The alternative architecture would be: write to DynamoDB, then separately publish to SQS or EventBridge, then subscribe a Lambda, then write the alert back. That's three services instead of one.

DynamoDB Streams collapses the first two into a built-in feature. The advantages over a separate message bus:

• 
  Zero infrastructure: no queue to create, no dead-letter queue to configure, no IAM policies for cross-service access


• 
  Guaranteed delivery: every successful DynamoDB write generates a stream record. No "forgot to publish" bugs.


• 
  Ordered processing: records arrive in write order within a shard. SQS standard queues don't guarantee ordering. SQS FIFO queues do, but require explicit deduplication IDs.


• 
  Same-table writes: the Lambda reads from DynamoDB and writes back to the same table. One set of credentials, one IAM policy, one table.


• 
  Cost: $0 at rest. No base cost when nobody is scanning. Lambda charges only for invocations.

The Lambda function

The full Lambda is 412 lines. Here's what each section does: