Debraj Paul

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.

What it is. User-generated content — comments, nicknames, image uploads — from multiple brand surfaces flows through an internal API gateway, is identity-checked via CIAM, then published to a Kafka request stream. An inbound Lambda dispatches to two in-house classifiers: a text moderation processor for comments and nicknames, and a media processor for images. Both publish verdicts to a separate Kafka response stream; an outbound Lambda picks up each verdict and notifies the originating brand surface. Image bytes are stored in S3; record metadata and S3 keys live in DynamoDB.

Why this shape. Two streams (request out, response in) localise replay — a failure in moderation never re-drives the entire pipeline. Both classifiers are owned in-house: text moderation was migrated off a third-party vendor, image moderation absorbed from a sister team, eliminating vendor cost and returning policy ownership to the product team. Per-brand rules (banned terms, severity thresholds) are hot-reloadable without redeployment.

What it is. A multi-tenant serverless budgeting platform built as a pnpm monorepo on AWS. Users upload bank statements (HDFC, SBI, Axis — PDF or CSV) via a GraphQL mutation; the statement lands in S3, an S3 event queues a message in SQS, and the txn-loaders Lambda parses and normalises the transactions into DynamoDB. A DynamoDB stream on the Transactions table immediately triggers the tag-loaders Lambda, which applies a deterministic NLP rule engine for known merchants and categories, falling back to Amazon Bedrock (Mistral) only for low-confidence matches. All 8 DynamoDB tables use tenantId as the partition key, giving hard data-boundary isolation between users.

Why this shape. S3 → SQS decouples ingestion from parsing — spiky upload volumes don’t block the GraphQL API. DynamoDB Streams replace polling entirely: as soon as a transaction is written, the categorisation worker fires. The hybrid NLP+AI strategy keeps Bedrock calls (and their cost) to a minimum; most common merchants are classified by rules in under a millisecond. AWS CDK provisions all resources — tables, queues, buckets, alarms, X-Ray groups — as reproducible stacks with explicit dependency ordering.