Design a Compliance and Audit Monitoring Solution — System Design Interview Practice

Interview prompt

Design a compliance and audit platform that immutably captures cloud API activity and configuration changes, evaluates controls, detects threats, and produces evidence for PCI-DSS, HIPAA, and SOC 2.

• Make append-only, time-synchronized audit events the evidence source and derive searchable findings, controls, and dashboards.
• Prevent tampering with encryption, retention locks, chained integrity proofs, restricted access, and independent account storage.
• Evaluate configuration continuously, correlate activity with identity and asset context, and route high-severity violations quickly.
• Explain missing events, duplicate delivery, legal holds, tenant isolation, privacy, retention, evidence export, and replay.

Requirements and scale assumptions

• Collect API logs, identity activity, configuration snapshots, vulnerability findings, and policy evaluations from cloud accounts.
• Search events and findings, show asset history and control status, assign remediation, and export signed audit evidence.
• Support control versions, exceptions with expiry, incident escalation, legal holds, retention rules, and auditor access.
• Retain required audit evidence for seven years with searchable recent data and lower-cost immutable archive tiers.
• Ingest bursty multi-account activity without dropping events or allowing one account to monopolize processing.
• Make collection, policy evaluation, notifications, and remediation idempotent with explicit event completeness tracking.
• Continue collecting and preserving evidence during rule-engine, search, dashboard, or notification outages.
• Monitor 10,000 cloud accounts, 100 million events per day, and seven years of retained evidence.
• Partition by tenant, account, event day, and asset; isolate high-volume accounts and bursty control-plane services.
• Keep recent indexes bounded while preserving encrypted raw events, snapshots, findings, and integrity proofs in archive.

• Audit ingest: 100M events/day — Event volume drives partitioning, archive throughput, integrity checks, and backpressure.
• Finding freshness: p95 <=5min — New high-severity configuration violations should be evaluated quickly, while archive writes remain durable.
• Durable boundary: Committed before async — Immutable collected events and signed snapshots are authoritative evidence; findings are derived.
• Async boundary: At-least-once workers — Keep policy evaluation, correlation, notifications, remediation, and dashboards asynchronous.

Key entities

• ResourceSpecresourceId, tenantId, desiredState, version, policyVersion, updatedAt

  Versioned desired state for a compliance and audit monitoring solution managed resource.

• OperationoperationId, resourceId, requestHash, step, attempt, status

  Durable compliance and audit monitoring solution reconciliation operation with per-step progress.

• PolicyVersionpolicyId, scope, version, rules, effectiveAt, status

  Auditable compliance and audit monitoring solution policy evaluated before provisioning or mutation.

• ReconciliationCheckpointresourceId, provider, observedVersion, cursor, lastError, updatedAt

  Provider-specific compliance and audit monitoring solution observation and recovery cursor.

Data flow

1. 1. Accept a desired-state commandThe compliance and audit monitoring solution control plane authenticates the tenant, validates policy and quotas, checks the expected version, and records the desired state.
2. 2. Plan a safe operationA planner turns compliance and audit monitoring solution desired state into ordered, bounded steps with dependency checks, blast-radius limits, and rollback metadata.
3. 3. Reconcile providers asynchronouslyWorkers apply compliance and audit monitoring solution operations through provider adapters, persist checkpoints, rate-limit calls, and treat unknown outcomes as observable state.
4. 4. Publish observed healthThe serving projection joins desired and observed compliance and audit monitoring solution state with operation status, policy version, freshness, and actionable errors.
5. 5. Recover and auditRetries, dead letters, drift detection, and operator approvals repair compliance and audit monitoring solution resources without losing the original command or provider evidence.

Deep dives and trade-offs

• Desired versus observed stateKeep compliance and audit monitoring solution desired state separate from provider-observed state and show both to operators. Make every reconciliation step conditional and resumable so a worker crash does not restart unsafe effects. Version policy and resource state so old operations cannot overwrite newer intent.
• Provider failures and unknown outcomesUse provider-specific idempotency tokens and query-after-timeout behavior for compliance and audit monitoring solution operations. Bound retries with exponential backoff, circuit breakers, and per-provider quotas. Route irreconcilable drift to an approval or quarantine path instead of retrying forever.
• Blast radius and operationsPartition compliance and audit monitoring solution work by tenant, region, cluster, or resource class and cap concurrent mutations. Audit who changed desired state, which policy allowed it, and what provider evidence was observed. Alert on drift age, operation backlog, failed steps, policy denials, and stale observations.
• Push versus pull reconciliationUse event triggers for fast response and periodic scans for missed events, drift, and recovery. A push-only compliance and audit monitoring solution controller silently misses changes when a provider event is lost.
• Central control plane versus provider-native controllersKeep policy, intent, and audit centralized while isolating provider-specific application logic behind adapters. A monolithic controller becomes hard to scale and couples unrelated provider failure domains.
• Automatic repair versus approvalAutomate low-risk, reversible compliance and audit monitoring solution changes and require approval for destructive or high-blast-radius operations. Full automation without policy or blast-radius controls can turn a transient signal into a widespread outage.