A) AuthN/AuthZ & service-to-service auth
Say
“Authentication is identity; authorization is permission. We enforce at the gateway and in the service (defense in depth).”
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
TemplateUsers (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
Say
“Secrets live in a central manager, delivered just-in-time, and rotated automatically with audit trails.”
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
TemplateStorage: • 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
Say
“TLS everywhere, and for sensitive fields we use envelope encryption so keys can rotate without rewriting all data.”
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 dataFacebook-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)
Say
“Privacy is an engineering workflow: classify → minimize → retain only what’s needed → delete reliably.”
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
Template1) 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
Say
“We defend at multiple layers: edge WAF + rate limits, then behavior/risk scoring, then step-up controls.”
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)
Say
“Compliance becomes implementable when you translate it into: data map, retention, DSAR workflows, and incident runbooks.”
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)
Say
“Security controls need monitoring: audit logs, anomaly alerts, and tested incident response.”
Security operations — template
TemplateAudit 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)
TemplateSet-Cookie: sid=...; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1800CSP starter — template
TemplateContent-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 callbacksFacebook-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.”