System context and components

OpenDPDP begins as a modular monolith with asynchronous workers and customer-side connector agents. The shape minimises distributed consistency while preserving boundaries that can be extracted when scale or deployment requires it.

System context

flowchart LR
  DP[Data Principal] -->|choices, requests, messages| PORTAL[Principal portal]
  STAFF[Privacy, legal, security, owners] -->|review and operate| UI[Enterprise console]
  APPS[Customer apps] -->|notices, consent, events| API[OpenDPDP API]
  UI --> API
  PORTAL --> API
  API --> CORE[Control plane]
  CORE --> QUEUE[Transactional outbox / jobs]
  QUEUE --> AGENT[Customer-side connector agent]
  AGENT --> SYS[Customer systems and data]
  CORE --> EVID[Evidence and audit store]
  CORE --> MSG[Customer-approved messaging providers]
  CORE --> AUTH[Customer identity provider]
  CORE -. reviewed/manual submission .-> REG[Board, CERT-In, sector authorities]

The control plane stores purposes, metadata inventory, pseudonymous subject references, cases, instructions, task state and evidence. Raw customer records remain in source systems unless the customer explicitly configures a bounded disclosure package.

Data and cross-border flow

flowchart LR
  subgraph IN["India boundary"]
    CH[Collection channel]
    SYS[(Customer system)]
    CP[OpenDPDP metadata control plane]
    AG[Connector agent]
    CH --> SYS
    CP -->|signed purpose-bound task| AG
    AG --> SYS
    SYS -->|minimal outcome| AG --> CP
  end
  subgraph OUT["Other jurisdiction"]
    PR[Processor / support]
    BK[(Backup / replica)]
  end
  SYS -->|approved scoped transfer| PR
  SYS -.->|configured replication| BK
  PR -->|subprocessor or remote access| PR

Every boundary-crossing edge has a versioned transfer record: source/destination countries, data/purpose, processor chain, remote access, foreign-State exposure, sector restriction, approval, effective window and evidence. The diagram does not imply that cross-border processing is prohibited; the policy engine evaluates current DPDP orders and independently applicable sector rules.

Modules

Module	Owns	Does not own
identity/tenancy	users, roles, entity scope, service clients	customer CIAM passwords
legal configuration	sources, status, obligations, controls	autonomous legal advice
inventory	systems, metadata, flows, classifications	bulk raw PII
notice/consent	immutable versions and receipts	customer content system
case management	requests, grievance, breach, tasks, clocks	source record mutation
retention	rules, holds, disposal orchestration	unreviewed destructive SQL
third party	vendors, instructions, contracts, evidence	procurement execution
assurance	DPIA, audits, findings, control tests	independent audit conclusion
integrations	connectors, credentials refs, sync/dead letters	plaintext secrets
evidence	audit events, artefact refs, manifests	claim of overall compliance

Modules share one PostgreSQL cluster initially but use schemas/ownership and no cross-module table writes. Commands call domain interfaces; read models join approved projections.

Trust boundaries

flowchart TB
  subgraph Public["Public / Principal boundary"]
    P[Portal and consent endpoints]
  end
  subgraph Edge["Edge boundary"]
    WAF[WAF, rate limits, bot/abuse controls]
    GW[API gateway]
  end
  subgraph Control["OpenDPDP control plane"]
    APP[Application]
    WRK[Workers]
    DB[(Tenant-scoped DB)]
    OBJ[(Encrypted evidence objects)]
    KMS[KMS/HSM]
  end
  subgraph Customer["Customer data plane"]
    A[Scoped connector agent]
    S[(Systems of record)]
  end
  P --> WAF --> GW --> APP
  APP --> DB
  APP --> OBJ
  APP --> KMS
  APP --> WRK
  WRK -->|mTLS, signed instruction| A --> S
  A -->|minimal result/evidence| WRK

Public endpoints, tenant admin, support, connector and evidence-export paths receive separate threat models and rate limits. Connector egress is allow-listed; control-plane inbound access is not required for customer VPC agents that poll signed instructions.

Transaction and event model

A command validates policy and optimistic version, writes the domain aggregate plus outbox event in one transaction, then returns. Workers deliver signed events at least once. Consumers deduplicate on (tenant_id, event_id) and use idempotency keys for destination actions. No distributed two- phase commit is assumed.

Partial fulfilment is normal:

parent case remains open
destination A = acknowledged
destination B = retrying
destination C = lawful exception
overall = partial

Legal configuration

Research maintainers publish a signed, immutable configuration bundle containing sources, effective dates, rules and control mappings. Customer legal reviewers compare and activate a version. Retroactive corrections create a migration/impact task; they do not rewrite historic decisions.

Availability under deadlines

The incident runbook and last approved contact/template pack are exportable for offline use. Connector agents spool signed results during control-plane outage. On recovery, sequence and resource versions prevent stale offline actions from overwriting newer decisions.

Extraction thresholds

Split a module only when independently scaling or deploying it materially helps: public consent ingest, connector orchestration and audit append may be early candidates. Keep legal configuration, cases and task coordination together until measured contention or sovereign placement requires separation.