System Design

Security, privacy, compliance — detailed guide

Practical AuthN/AuthZ, secrets, encryption, PII/retention, abuse prevention, and compliance patterns — with a Facebook-like Home Feed example in every section.

A) AuthN/AuthZ & service-to-service auth

Core concepts

  • AuthN: who the caller is (user/app/service).
  • AuthZ: what actions are allowed (scope/role/policy + resource checks).
  • Least privilege: narrow scopes, short-lived credentials, auditable decisions.
Auth stack — template
Template
Users (web/mobile): • OIDC (OAuth2 Auth Code + PKCE) • Short-lived access token (minutes) + rotating refresh token • Phishing-resistant MFA (WebAuthn/passkeys) for sensitive flows Services: • mTLS (service identity) + per-request authZ policy • Or OAuth2 Client Credentials for service tokens (short TTL) AuthZ models: • RBAC (roles) for coarse permissions • ABAC (attributes like tenant/region/risk) • ReBAC (relationship/graph: follower, member, owner) Critical validation: • Validate iss, aud, exp/nbf (clock skew), signature, and scope/permissions • Never trust identity headers unless injected by a trusted gateway
Facebook-like Home Feed — Auth design
Example
• Gateway validates JWT for GET /v1/feed and write endpoints. • Feed service re-checks authorization for privacy (blocks, private accounts). • Internal hops: mTLS identity between API Gateway ↔ Feed Service ↔ Graph Service. • Step-up auth (WebAuthn) for account recovery or changing email/password.
Pitfalls
  • Long-lived tokens with no revocation plan
  • Skipping audience (aud) checks or trusting any issuer
  • Bearer tokens in logs/traces
  • Using localStorage for tokens in browsers (XSS risk)
  • No CSRF protection when using cookies for sessions

B) Secrets management & rotation

What counts as a secret

  • API keys, DB creds, signing keys, private keys, OAuth client secrets, webhook secrets.
  • Also: “secret-like” values (connection strings, internal endpoints, salt/pepper).
Secrets program — template
Template
Storage: • Use a managed secret store (Vault / AWS Secrets Manager / GCP Secret Manager) • Encrypt at rest; strict IAM; every access audited Delivery: • Do NOT bake into images or repos • Pull at startup via short-lived identity; or sidecar agent • Minimize exposure: avoid env var dumps; redact logs Rotation: • TLS certificates: ≤ 90 days (automated) • DB creds: dynamic/leased creds when possible • API keys: 30–90 days; support key overlap during rotation • Signing keys: key sets (kid) + rollout/rollback plan Break-glass: • Strongly controlled emergency access (hardware keys), time-bound and audited
Facebook-like Home Feed — secrets in practice
Example
• API Gateway uses rotated JWT verification keys via JWKS caching. • Feed/Graph services use dynamic DB creds (leased) and auto-rotated mTLS certs. • Moderation webhooks use per-integration secrets; rotation supports overlap windows.
Pitfalls
  • Hard-coding a “secret zero” (initial root key) in config
  • No rotation runbook (keys never change)
  • Secrets leaking into logs, crash dumps, or analytics
  • Storing secrets in CI variables without access controls/audit

C) Encryption in transit & at rest — envelope encryption

What to encrypt

  • In transit: TLS 1.2+ at the edge; mTLS internally where appropriate.
  • At rest: disk/volume encryption + app-level encryption for high-sensitivity fields.
  • Backups: encrypted + immutable storage (WORM) + access logging.
Envelope encryption — template (pseudocode)
Template
# CMK (KMS/HSM key) never leaves the service boundary
dek_plain, dek_wrapped = KMS.generate_data_key(CMK)

ciphertext = AEAD.encrypt(plaintext, dek_plain, aad=metadata)

store({
  "ciphertext": ciphertext,
  "dek_wrapped": dek_wrapped,
  "alg": "AES-256-GCM",
  "key_id": "cmk_123"
})

# Rotation: re-wrap DEKs with a new CMK without re-encrypting the data
Facebook-like Home Feed — encryption choices
Example
• TLS for all external endpoints; mTLS for service-to-service. • Encrypt sensitive fields like email/phone in user profile with envelope encryption. • Analytics receives only redacted or tokenized identifiers (no raw PII).
Pitfalls
  • One global key for everything (blast radius + rotation pain)
  • Plaintext temp files or debug dumps containing sensitive fields
  • No audit of decrypt operations
  • Sending raw PII into logs/analytics pipelines

D) PII handling: minimization, retention & RTBF (deletion)

PII lifecycle

  • Classify: tag fields at ingest (Public / Internal / Sensitive / Restricted).
  • Minimize: collect only what is necessary; reduce copies; avoid exporting raw PII.
  • Retention: explicit time limits per dataset; automated TTL where possible.
  • RTBF deletion: delete in DB + propagate to cache, search, logs, analytics; backups expire per policy (and are not “restored into production” without deletion replay).
RTBF deletion pipeline — template
Template
1) Identify subject (user_id / stable identity key) 2) Emit deletion event (versioned): user.delete.requested 3) Fanout workers purge: • primary DB rows + indexes • caches (tenant-aware keys) • search documents • analytics tables (if required) or enforce TTL 4) Verify (queries + audit evidence) 5) Backups: expire per retention; if restored, reapply deletion events 6) Produce completion record / certificate
Facebook-like Home Feed — PII & deletion
Example
• User profile includes: email/phone + privacy controls. • Logs store request_id and user_id (hashed/tokenized where possible), not raw email/phone. • Deleting an account purges: - profile records - feed materialization references - search index docs (username) - caches + CDN variants - moderation/report links per policy
Pitfalls
  • Forgetting caches and search indexes during deletion
  • PII in logs/traces, support tickets, or crash dumps
  • Indefinite retention “just in case”
  • Treating hashing as anonymization without considering re-identification risk

E) Abuse prevention: WAF, bot controls, spam/fraud signals

Defense layers

  • Edge: WAF rules, DDoS protection, token-bucket rate limits, geo/IP reputation.
  • Application: device fingerprinting (privacy-aware), anomaly detection, velocity rules, content filtering.
  • User safety: reporting flows, moderation queues, appeals, shadow bans where appropriate.
Abuse controls — template
Template
• Rate limit at gateway (per user/app/IP) with 429 + Retry-After • Challenge on suspicion: CAPTCHA / proof-of-work / email or phone verification • Spam & fraud detection: velocity limits, reputation scores, risky geo patterns • Content safety: ML + rules + human review, plus audit trails and appeals • Protect writes more than reads; cost-weighted quotas (write=5, read=1)
Facebook-like Home Feed — abuse controls
Example
• Like/comment endpoints are more strictly rate-limited than GET /v1/feed. • Suspicious accounts trigger step-up verification before posting. • Reports endpoint (POST /v1/content/{content_id}/reports) has abuse throttles + moderation triage queues.
Pitfalls
  • Relying only on IP blocking (easy to bypass, harms shared networks)
  • Blanket CAPTCHAs that kill UX
  • No replay protection for webhooks or write operations
  • No audit trail for moderation actions

F) Compliance: GDPR/CCPA, PCI (practical engineering view)

GDPR / CCPA (operational)

  • DSAR: access/export, correction, deletion (RTBF), portability.
  • Vendor risk: DPAs, subprocessors, least-privileged access, audit logs.
  • Cross-border/data residency: region pinning + contractual controls.
  • Breach readiness: detection + triage + comms runbook.

PCI (payments)

  • Minimize scope: hosted payment fields/pages from a compliant provider.
  • Avoid storing PAN/CVV; tokenize and store only last4 + brand when needed.
Facebook-like Home Feed — compliance mapping
Example
• GDPR/CCPA: deletion pipeline covers profile, feed caches, search docs, and analytics per policy. • Vendor DPAs: moderation vendors and analytics platforms are audited and access-controlled. • If payments exist (subscriptions): use hosted checkout, keep the feed system out of PCI scope.
Pitfalls
  • Assuming legal will ‘handle it’ without engineering workflows
  • Accidentally storing payment data (PAN/CVV) in logs
  • No DSAR tooling or runbooks (manual, slow, inconsistent)
  • Data residency requirements not reflected in routing/storage design

G) Operational guardrails (audit, monitoring, incident response)

Security operations — template
Template
Audit logs: • Auth events (login, MFA changes), privilege changes, key usage (KMS decrypt), policy updates Detection: • WAF spikes, unusual auth failures, token anomalies, secret access bursts, impossible travel patterns Response: • Break-glass access (hardware keys), rotating credentials, token revocation / session purge • Incident roles + comms template + postmortem actions with owners & dates
Facebook-like Home Feed — monitoring & response
Example
• Alerts on abnormal login failures and unusual report/like velocity. • KMS decrypt spikes trigger investigation (possible data exfil attempt). • “Disable posting” kill switch for emergencies while keeping GET /v1/feed available.

H) Quick checklists (fast interview answers)

AuthN/AuthZ
  • OIDC (PKCE) for users
  • Short-lived tokens + rotation
  • mTLS for services
  • RBAC/ABAC/ReBAC as needed
Secrets & keys
  • Central manager + audit
  • Automated rotation (certs ≤ 90d)
  • Envelope encryption for sensitive fields
Privacy
  • Classify → minimize → retain
  • RTBF pipeline to caches/search/analytics
  • Redact logs/traces
Abuse
  • WAF + token buckets
  • Risk scoring + step-up controls
  • Moderation workflow + audit
Facebook-like Home Feed — checklist summary
Example
• Short-lived JWTs at edge; mTLS inside; privacy checks in service. • Secrets via manager + rotation; envelope encrypt sensitive profile fields. • Delete reliably across DB + cache + search + analytics + backups policy. • Rate-limit writes + moderation workflow for reports/spam.

I) Sample snippets (copy/paste friendly)

JWT claims — template (example payload)
Template
{
  "iss": "https://idp.example.com",
  "sub": "user_123",
  "aud": "feed-api",
  "scope": "feed:read posts:write",
  "jti": "9f9d7c3a-0a6e-4e5b-b18e-6c3f25a1e1df",
  "iat": 1731080000,
  "exp": 1731081800
}
Cookie flags — template (browser sessions)
Template
Set-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1800
CSP starter — template
Template
Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<random>';
  object-src 'none';
  frame-ancestors 'none';
  base-uri 'self';
Webhook verification — template
Template
# Verify signature to prevent spoofing/replay
sig = HMAC_SHA256(secret, raw_body)
if !constant_time_equals(sig, request.headers["X-Signature"]):
  reject(401)

# Add replay protection (timestamp + nonce) for high-risk callbacks
Facebook-like Home Feed — snippet placement
Example
• Webhooks for moderation callbacks use HMAC verification + replay protection. • JWT validation enforces iss/aud/exp; request_id used for audit correlation. • CSP protects the web UI against script injection.

J) One-liners (ready for interviews)

  • “Least privilege + short-lived tokens; step-up auth for sensitive actions.”
  • “Gateway validates identity; services enforce resource-level authorization.”
  • “mTLS for service identity; never trust identity headers from untrusted hops.”
  • “Envelope encryption: DEK per object, wrapped by CMK; decrypt calls are audited.”
  • “Privacy is a pipeline: classify → minimize → retain → delete across DB/cache/search/analytics.”
  • “WAF + rate limits at edge; risk scoring and moderation workflow for abuse.”
  • “We reduce PCI scope via hosted payments; DSAR/RTBF is operationalized via APIs and runbooks.”