Audience Architecture

Audience activation runs as a layered pipeline: create the segment in Cloud, orchestrate with Airflow, track membership state, activate on EKS, and deliver through EdgeTag to ad platforms.

Control plane

Users create or edit segments in the Cloud Portal. dashboard-backend (SegmentServiceImpl) handles the request, persists configuration in PostgreSQL (RDS) as the source of truth, and kicks off orchestration. An Athena mirror (async, pool of 4) keeps analytical copies in sync. Caffeine + Redis provide L1/L2 caching for hot reads.

Orchestration (Airflow MWAA)

Each segment/app runs an Airflow DAG with max_active_runs = 1. Typical tasks:

Task	Purpose
create_queue	Ensure the SQS FIFO queue exists
dynamo_reset	Purge DynamoDB membership on a full resync
dbt build	Build segment_users in Athena
delta_producer	Emit IN/OUT membership deltas downstream

State & queue

• DynamoDB (segment_membership_state) — Membership state with ~90-day TTL (scaled ×8 for capacity planning)
• Amazon S3 — Delta Parquet snapshots
• SQS FIFO (segment-activation-jobs) — Activation jobs from delta_producer; DLQ after 3 retries; 300s visibility timeout

Activation (EKS)

EKS workers (about 3–5 replicas) long-poll SQS FIFO. For each job they:

1. Fetch PII from Athena (view_users)
2. Build entity payloads to the EdgeTag contract
3. Ack — delete the SQS message and update RDS on success

Destinations (EdgeTag)

EdgeTag /audience applies identity + consent, then fans out to:

• Meta CAPI (labels — Graph v25.0)
• Google Ads (Customer Match)
• TikTok (Audiences)

Ops notes

IAM uses a SegmentActivationPolicy scoped to DynamoDB + SQS. CloudWatch watches queue depth and DLQ. DynamoDB single-partition write ceiling is about 1000 WCU/s.

See Segmentation to create audiences and Activation to connect channels.