Selected work

Public reference · Serverless backend

Serverless Streamer Monitoring & Campaign Analytics

An event-driven AWS workflow that detects when sponsored creators go live, starts session monitoring, and records audience, chat, transcript, and mention telemetry.

Type
Serverless monitoring workflow
Role
Architect / engineer
Status
Public reference
Focus
Event-driven monitoring and attribution
AWS LambdaStep FunctionsEventBridgeS3DynamoDBPythonPlatform adaptersCampaign analytics
System map

The operating path.

A deliberately simplified architecture view. The case study below explains where the important guarantees and decisions live.

  1. 01Scheduled roster poll
  2. 02Live detection
  3. 03Session lock
  4. 04Step Functions loop
  5. 05Telemetry events
  6. 06Session summary

The problem

Why this system needed to exist.

A growing sponsored-creator program needed more than a manually checked snapshot. Teams needed to know which creators were live, how each session changed over time, and when a product or campaign code appeared in chat or transcript text.

The first implementation also had to work before one platform offered a supported public API, while remaining adaptable when official APIs became available.

The system

How the pieces work together.

EventBridge checks a configurable creator roster on a schedule. Offline checks stay cheap; when a creator is live, the system claims a unique session and starts a Step Functions execution.

The state machine loops while the stream remains active, collecting normalized metadata, viewer snapshots, optional chat and transcript events, and product mentions into a partitioned event store. It then finalizes per-session metrics.

01

Cheap when nothing is happening

The roster poll and the longer monitoring loop are separate. Offline creators do not consume a long-running workflow.

02

Session identity and locking

A DynamoDB-backed claim prevents duplicate monitoring for the same platform, creator, and stream ID.

03

Adapter boundary

Platform-specific collection is normalized behind a provider interface, allowing web-facing responses or official APIs to feed the same downstream system.

Source boundary

The public repository is an anonymized reference. It clearly distinguishes recovered historical source from reconstructed components and contains no account IDs, tokens, private creator roster, or customer campaign data.

A system like this on your roadmap?

Let’s make the hard parts explicit.

Discuss the project