Privacy / PII Request Orchestrator

Compliance · GDPR Article 15 + 17 · Async fan-out across 6+ services

Privacy / PII Request Orchestrator Architecture Left-to-right: User sends a privacy request to OneTrust (privacy management vendor), which fires a webhook to the Privacy Broker API. The broker forwards to the Compliance Request Orchestrator (primary actor). The orchestrator fans out via a Kafka request stream to 6 downstream services. Each service publishes its result to a Kafka result stream. The orchestrator aggregates and fires a fulfillment callback. State is stored in DynamoDB and a service registry. GDPR Article 15 and 17 compliance. Cross-cutting: CloudWatch, OpenTelemetry, IAM, IaC. ENTRY VENDOR BROKER ORCHESTRATOR ASYNC BACKBONE User privacy request OneTrust Privacy Management Vendor Privacy Broker API Compliance Request Orchestrator subject-request-ID = idempotency key Request State DB (DynamoDB) Service Registry S3 → Access Data export GDPR Art. 15 + 17 · Audit trail Kafka User Request Stream Kafka User Result Stream Comments Service Users / Profile Service Saved Items Service Brand-specific Services Moderation Service Media Service webhook fulfillment callback CROSS-CUTTING CloudWatch · OpenTelemetry · IAM · IaC (CDK / CloudFormation) LEGEND sync HTTP async event primary actor compliance

What it is. A user privacy request (right of access or right to erasure) enters via OneTrust and is forwarded by a third-party broker to the Compliance Request Orchestrator. The orchestrator looks up which downstream services hold PII for that user via a service registry, then fans out across a Kafka request stream. Each downstream consumes its slice, processes (delete or export), and publishes a per-service result. The orchestrator aggregates results and calls the broker’s fulfillment API once the aggregate state flips to complete.

Why this shape. The subject-request-ID drives idempotency end-to-end, so re-deliveries at any hop are safe. A service registry — rather than hardcoded routing — lets new PII-holding services join compliance by registering, with no orchestrator change. Two separate Kafka streams (request out, result in) give each downstream a clean inbound contract and the orchestrator a clean aggregation contract. State is split into per-service status and an aggregate; the aggregate flips to complete only when every individual settles, gating the fulfillment callback.