skip to content

learn.smmeyer.devsystem-design09

menu

system-design/09

production · core · ~3h practice

Security & abuse resistance

outcome

Threat-model identity, tenancy, data, and abuse as first-class architecture.

Plan a practice session · ~3h including exercises
Read + trace the worked example
25 min
Assignment + constraint variations
100 min
Timed drill + repeated explanations
35 min
Closed-book recall + self-review
20 min

This is a suggested practice budget, including drawing, variations, and repeated drills. Reading is the first block. Split the work across sessions and use the rubric to judge when to move on.

why this matters

Security answers are strongest when attached to trust boundaries and valuable assets. Public AI systems also face economic abuse: attackers can turn stolen credentials or automation into real compute cost.

coverage

  • Identity: sessions, JWTs, OAuth, token rotation.
  • Authorization: RBAC, ABAC, resource ownership, policy enforcement.
  • Protection: TLS, encryption at rest, secrets and key management.
  • Tenancy: logical/physical isolation, noisy neighbors, scoped credentials.
  • Abuse: validation, rate limits, bot/fraud signals, cost ceilings.
  • Governance: audit logs, privacy, retention, deletion.

mental model

Authenticate the actor, authorize the action, constrain the effect, record the decision.

  1. 1 →Authenticate

    Who are you?

  2. 2 →Authorize

    May you do this?

  3. 3 →Constrain

    Least privilege

  4. 4 →Audit

    What happened?

Read in numbered order: authenticate → authorize → constrain → audit.

lessons

01Draw trust boundaries

Mark browser, edge, application, tool sandbox, data plane, and external systems. Identify assets and attacker goals. Authentication establishes identity; authorization must still run at every protected resource boundary.

Authentication establishes who is making a request; authorization decides whether that identity may perform this action on this resource now. A valid session does not imply access to every file. Derive tenant identity from trusted authentication context, then check the requested object's owner and sharing policy. Never let a caller's arbitrary tenant_id field define the security boundary.

Draw where trust changes: browser to edge, edge to service, service to storage, worker to provider. At each boundary, list the credential, allowed operation, and validation performed. A signed download URL delegates access for its lifetime; it is effectively a temporary credential. Choose its scope and expiry based on how quickly revocation must take effect.

Threat modeling is a disciplined walkthrough of assets and possible misuse. For a file service, protect confidentiality of bodies, integrity of permissions, and availability of uploads. Trace a guessed object ID, a stolen link, a malicious upload, and a revoked member. Match each to an enforcement point and a test. Saying “encrypt the database” leaves most of those paths unanswered.

  • Short-lived, scoped credentials limit blast radius
  • JWT validation includes signature, issuer, audience, and expiry
  • OAuth delegates access; it is not authorization policy by itself

02Multi-tenancy is a data-flow property

Carry tenant identity from authenticated request through cache keys, queries, events, object paths, logs, and tools. Enforce policy server-side. High-risk workloads may need physical isolation beyond row filters.

Tenant isolation must survive every derived representation: database rows, search indexes, caches, exported files, logs, and asynchronous jobs. A perfectly filtered API can still leak through a cache keyed only by file ID or a worker that trusts an old permission snapshot. Carry trusted tenant context and resource identity into downstream work.

Use defense in depth with explicit ownership. Application checks can apply sharing rules; database policies can guard against missing filters; scoped storage credentials can limit a worker's reach. These controls need a consistent tenant model and tests for administrative or migration paths. A privileged maintenance script can bypass an otherwise careful request flow.

Revocation is a time problem as well as a data problem. Decide when access must stop for cached previews, already queued jobs, and active downloads. Recheck before publishing sensitive results and before consequential effects where required. If an already issued URL remains valid for five minutes, describe that exposure and decide whether the product can accept it.

  • Default-deny resource access
  • Avoid confused-deputy tool calls
  • Partition quotas and concurrency per tenant

03Abuse is reliability plus economics

Layer cheap controls before expensive work: input limits, identity reputation, token buckets, anomaly detection, and spend caps. Preserve headroom for trusted traffic and record appeal/recovery paths for false positives.

Abuse often uses valid requests at economically harmful volume. A free account can submit expensive exports, large uploads, or long-running inference requests. A request-rate limit treats cheap and costly operations alike. Combine caller, tenant, operation, concurrency, byte, and spend limits, using an estimate on admission and reconciliation after completion.

Place admission before scarce work. If the system parses a huge archive or invokes a model before checking quota, the limit arrives too late. Bound input size, expansion ratio, execution time, and output volume. Protect shared resources against many accounts acting together as well as one noisy tenant; per-account limits alone do not stop distributed abuse.

Separate authentication failures, policy denials, quota exhaustion, and upstream outages in telemetry. Otherwise an attack can look like an unexplained reliability drop. Audit sensitive access with resource and principal identities while restricting access to the audit log itself. Recovery includes credential rotation, revocation, and determining what data was exposed.

  • Rate-limit by user, tenant, IP, and credential as appropriate
  • Audit policy changes and privileged actions
  • Minimize and expire sensitive data

worked example

An authenticated user requests another tenant's file

GET /files/123 is authenticated, but file 123 belongs to a different workspace. A cached response exists under the key file:123.

  1. Authentication establishes who is calling; it does not establish access to file 123. Resolve membership and object permissions server-side.
  2. Scope cache entries and database queries to the authorized tenant and object policy. A globally unique ID alone is not an authorization check.
  3. Issue short-lived download access only after authorization and avoid logging secret-bearing URLs.
  4. Bound downloads, expensive scans, and signed-link creation by tenant and account risk; log denied access for investigation without exposing file existence unnecessarily.

Design decision: Authorize every object access at the service boundary and preserve that scope through caching and storage.

Limit: A tenant-prefixed cache key prevents one mix-up but does not replace authorization or handle permission revocation by itself.

Teaching scenario · traffic, prices, and capacity values are illustrative.

assignment

Produce: A threat model and authorization matrix for a shared-file service.

Paper, a text editor, or a spreadsheet is enough. Model access and paid services are optional.

  1. List assets, identities, trust boundaries, and attacker-controlled inputs.
  2. Trace upload, preview, share, download, and revoke; define object authorization and audit evidence for each.
  3. Walk through guessed IDs, leaked URLs, oversized uploads, and quota abuse; revise the controls and failure responses.

Change a constraint

  • A member loses access while a cached preview and signed URL remain valid.
  • An attacker distributes requests across many free accounts.

Self-review rubric

  • Checks cover objects as well as endpoints.
  • Tenant scope survives caches and asynchronous workers.
  • Cost limits and revocation behavior are explicit.

If a criterion is missing, revise that part of the artifact before rating your practice below.

Compare a sample artifact after your attempt

One defensible answer under these assumptions. Compare the reasoning and checks with your work; other designs can satisfy the same contract.

Files are private to a workspace. Reads require current membership; signed body access has an explicitly bounded lifetime.

Asset: file body + metadata; principal: authenticated member
Member T / file T / allowed role → read
Member T / file U             → deny
Revoked member / file T       → deny new metadata/body grants
Worker / preview job         → scoped file capability, not tenant-wide secret
Read: authenticate → derive tenant → authorize file → cache/body lookup
Cache: tenant + resource + representation; no public private-file entry
Audit: principal, resource, decision, policy version; restricted log access

A cache key is defense in depth, not authorization. A cached preview and previously issued URL need a revocation policy. Economic abuse controls should limit bytes, concurrent expensive work, and spend before processing. Distributed accounts may require aggregate or risk-based limits as well as per-account caps.

Check your artifact

  • A guessed file ID from another workspace fails before publication.
  • A revoked member cannot obtain a new grant; the lifetime of already issued grants is stated.
  • Search, previews, exports, and workers preserve the same tenant/resource boundary.

A tempting mistake: Authentication proves identity, not permission to file 123. Moving the check behind a cache hit creates a leak.

cumulative practice

Relay · build and evolve a private file service

Project brief

Keep one design document for Relay, a tenant-aware file service. Start with 100k daily users, ten downloads per user/day, 10k uploads/day, 1 MB typical bodies, 30-day retention, and a 5× download peak. Files are private to workspaces. Treat these as fictional planning assumptions. Later chapters add previews, recovery, regional constraints, compute, and an assistant. Record each change rather than replacing the earlier version; the final review combines the whole packet. These activities share the chapter's existing practice budget.

Keep one project document across this track. Reconstruct earlier reasoning before opening notes, then revise the same artifact. Use part of the assignment and review budget for this work. If you enter mid-course, sketch the earlier decisions first using the linked chapters.

Add to your project: Relay's end-to-end tenant and revocation matrix.

Without notes, trace a private download through metadata and cache. Revoke a member while a preview is queued and another URL remains valid. Specify the enforcement point and observable evidence for each path, including any accepted revocation delay.

Compare cumulative reasoning after your attempt

Authorize current membership before issuing a download grant and before publishing a preview to a caller where required. Carry trusted tenant and file identity in jobs; isolate credentials. Existing signed URLs retain whatever bounded lifetime the product accepted, unless access is mediated by a revocable serving path. Record policy decisions in restricted audit logs, not unbounded metric labels. Cached bodies do not independently grant access.

Keep your first attempt and revision together. If your answer differs, identify the assumption or mechanism that explains the difference before rating your recall.

senior signal

Walk one threat end-to-end: stolen API key → distributed requests → expensive inference. Show detection, budget reservation, cutoff, audit, and credential rotation.

failure patterns

  • Treating a valid JWT as permission for any object
  • Forgetting tenant identity in cache or vector-search filters
  • Logging prompts, secrets, or tool outputs indiscriminately
  • One global rate limit that lets a noisy tenant starve others

knowledge checks

Start with these quick checks, then explain the closed-book questions in your own words.

  1. 01Where must tenant identity appear?

    select an option to check your answer

  2. 02Best place for spend control?

    select an option to check your answer

closed-book recall

Close the worked example and explain these from memory. Answers are self-reviewed. Drafts stay on this page; save anything you want to keep in chapter notes.

Rate the assignment and recall together

Use the assignment rubric as evidence. Completion is your own judgment; this score schedules practice.

interview drill

Secure a multi-tenant coding-agent service that can execute shell commands against customer repositories.

  • untrusted repos
  • network access
  • secrets
  • human approval
compare a strong approach after your attempt

Use per-run ephemeral sandboxes and scoped repo credentials; default-deny network and filesystem reach. Separate model suggestions from privileged execution, require approval for high-impact operations, scrub secrets from context/logs, sign tool policies, bound time/CPU/spend, and keep an immutable audit trail.

Compare decisions and failure behavior, then repeat with a changed constraint. Keep your own wording.

Use the timed mock workspace →

references

Sources offer deeper context. Provider capabilities and API contracts can change; check current official docs before implementing.

notes

saved locally