← Cloudflare Interview Insights

Cloudflare·Software Engineer·Onsite - System Design / Architecture·Senior

Senior
Jun 2026

Summary

Cloudflare systems design round focused entirely on building an encrypted key-value store from scratch. Pretty deep dive, more implementation-heavy than I expected for a design interview.

Questions Asked (4)

Q1

Design and implement an encrypted key-value store where values are encrypted at rest using a user-supplied password. Include put, get, delete, and list operations, plus user registration and login.

System DesignTechnical Trade-offsAPI & Integrations
Author's notes

This is where I spent most of the session.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a high-level architecture that separates authentication, key management, and encrypted storage. Walk through the API design and data model, emphasizing encryption at rest with a user-supplied password, and discuss trade-offs around security, performance, and scalability.

Pro tip: Demonstrate awareness of Cloudflare's edge computing context by discussing how to handle encryption/decryption at the edge without exposing keys, and mention using envelope encryption with a key derivation function like Argon2 to derive a master key from the password.

1. Clarify Requirements and Constraints

Ask about expected scale, consistency needs, security requirements, and whether the store is local or distributed. Clarify if the password is per-user or per-store, and how authentication should work.

2. Design High-Level Architecture

Outline components: authentication service, key management, encrypted storage backend, and API layer. Consider using a client-side encryption approach where the server never sees the plaintext or the password.

3. Define API and Data Model

Specify endpoints for register, login, put, get, delete, and list. Describe how data is stored: each value encrypted with a unique data key, which is itself encrypted with a master key derived from the user's password.

4. Detail Encryption and Key Management

Explain the use of a strong KDF (e.g., Argon2) to derive a master key from the password, and envelope encryption for values. Discuss secure storage of salts and encrypted data keys.

5. Discuss Trade-offs and Scalability

Address trade-offs: security vs. performance (KDF cost), consistency vs. availability, and how to scale (e.g., sharding, caching). Mention potential attacks and mitigations.

Key Points to Mention

  • Use of a strong key derivation function (e.g., Argon2, PBKDF2) with salt to derive encryption keys from passwords.
  • Envelope encryption: each value encrypted with a unique data key, which is encrypted with a master key.
  • Client-side encryption to ensure the server never sees plaintext or the user's password.
  • Secure authentication: hashing passwords with salt and using sessions or tokens (e.g., JWT).
  • API design: RESTful endpoints with proper HTTP methods and status codes, and idempotency for put/delete.
  • Trade-offs: performance overhead of encryption/decryption, key rotation, and handling large values.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

How would you handle key derivation from a user password? Walk through your choice of algorithm, the role of salt, and how you'd store what's needed to re-derive the key on login.

System DesignTechnical Trade-offs
Author's notes

I went with PBKDF2 first since I could explain the iteration count tuning, then mentioned Argon2 as the stronger modern option.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the use case (e.g., password authentication vs. encryption key derivation) and then walk through a modern, memory-hard algorithm like Argon2id, explaining each parameter's role. Emphasize that salt and parameters must be stored alongside the hash, and that the derived key is never stored—only used for verification or encryption.

Pro tip: Mention that you would use a constant-time comparison function to prevent timing attacks, and that you'd consider using a pepper (a secret key stored separately) for defense in depth.

1. Clarify the goal and threat model

Determine whether the derived key is for password verification or for encrypting data, and identify threats like brute-force, rainbow tables, and side-channel attacks.

2. Choose a modern KDF algorithm

Select a memory-hard algorithm like Argon2id (or scrypt/bcrypt as fallbacks) and justify why it resists GPU/ASIC attacks better than PBKDF2.

3. Explain salt and parameter selection

Describe generating a unique, random salt per user and tuning parameters (memory, iterations, parallelism) to balance security and performance.

4. Detail storage format

Store the algorithm identifier, parameters, salt, and resulting hash (or encrypted data) in a structured format like a string or database record.

5. Describe login verification

On login, retrieve the stored parameters and salt, re-derive the key using the same algorithm, and compare it to the stored hash using a constant-time comparison.

Key Points to Mention

  • Use of a unique, cryptographically random salt per user to prevent rainbow table attacks.
  • Selection of Argon2id as the recommended algorithm, with parameters like memory cost, time cost, and parallelism.
  • Storage of algorithm, parameters, and salt alongside the hash (e.g., in a modular crypt format like $argon2id$v=19$m=65536,t=3,p=4$...).
  • Never store the derived key itself; only store the hash for verification or use the key for encryption and store the ciphertext.
  • Constant-time comparison to avoid timing attacks during verification.
  • Consideration of a pepper (secret key) stored separately from the database for additional security.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

For each write operation, how do you handle the IV or nonce, and why does it need to be unique per write rather than per user?

System DesignTechnical Trade-offs
Author's notes

Nailed this one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Explain that IVs/nonces must be unique per encryption operation to ensure semantic security, and describe how you generate them (e.g., random, counter-based, or derived from unique write identifiers). Emphasize the trade-offs between different methods and how you prevent reuse in distributed systems.

Pro tip: Mention that for AES-GCM, nonce reuse is catastrophic—it can leak the authentication key and allow forgery—so you might use a deterministic construction like a counter combined with a per-key random prefix, or leverage a service like Cloudflare's own distributed counter if available.

1. Define the requirement

State that IVs/nonces must be unique per encryption operation under the same key to avoid catastrophic failures like key recovery or plaintext leakage.

2. Choose a generation strategy

Describe common methods: random (with sufficient entropy), counter-based (monotonic), or deterministic (e.g., hash of write ID). Discuss pros and cons.

3. Ensure uniqueness in distributed systems

Explain how to coordinate across nodes: use a centralized counter, partition key space, or include node ID in the nonce.

4. Handle key rotation and persistence

Note that nonce uniqueness is per key, so when rotating keys, you can reset counters or use new random prefixes.

5. Validate and monitor

Mention the importance of testing and monitoring for nonce reuse, and having fail-safes to prevent it.

Key Points to Mention

  • Semantic security: unique IVs ensure identical plaintexts produce different ciphertexts, preventing pattern analysis.
  • Catastrophic failure in AES-GCM: nonce reuse allows an attacker to recover the authentication key and forge messages.
  • Random IVs: need 96-bit random for GCM; collision probability after 2^32 messages is non-negligible, so counter-based is safer for high volume.
  • Counter-based nonces: require persistent state and coordination to avoid reuse across restarts or multiple writers.
  • Deterministic nonces: can use a unique write ID (e.g., UUID) hashed to a nonce, but must ensure no collisions.
  • Key rotation: nonce uniqueness is scoped to a key, so rotating keys periodically mitigates risks.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

What happens when a user provides the wrong password during a get operation? How does your system detect and surface that error?

System DesignRoot Cause Analysis
Author's notes

Short answer: with authenticated encryption like AES-GCM, the tag verification fails and you get a decryption error before any plaintext is returned.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Walk through the end-to-end flow of a get operation with an incorrect password, focusing on authentication, error detection, and how the error is surfaced to the user. Emphasize security best practices (e.g., not revealing whether the key exists) and observability (logging, metrics, tracing) for debugging. Tailor your answer to Cloudflare's scale and distributed systems context.

Pro tip: Mention that you should never log the password or the secret itself, and that error messages should be intentionally vague to prevent oracle attacks. Also, highlight how you'd use structured logging and distributed tracing to correlate the error across services without exposing sensitive data.

1. Authentication and Authorization

Explain how the system verifies the provided password against the stored credential (e.g., hashed comparison) and checks if the user has permission to perform the get operation.

2. Error Detection

Describe how the system detects the mismatch (e.g., hash comparison fails) and distinguishes between authentication failure and other errors like missing key or network issues.

3. Error Surfacing

Detail how the error is propagated back to the client: HTTP status code (e.g., 401 Unauthorized), error message (generic to avoid leaking info), and any error codes for programmatic handling.

4. Observability and Logging

Explain what is logged (e.g., timestamp, user ID, operation, error type) without sensitive data, and how metrics and traces help diagnose issues at scale.

5. Security Considerations

Discuss measures to prevent timing attacks, brute force, and information leakage, such as constant-time comparisons, rate limiting, and generic error messages.

Key Points to Mention

  • Use of constant-time comparison for password hashes to prevent timing attacks.
  • Returning a generic error message like 'Invalid credentials' rather than 'Wrong password' or 'Key not found' to avoid revealing sensitive information.
  • Proper HTTP status codes: 401 Unauthorized for authentication failures, 403 Forbidden for authorization failures.
  • Logging the error with sufficient context (user ID, operation, timestamp) but never logging the password or secret.
  • Emitting metrics (e.g., authentication failure count) and traces to monitor and alert on suspicious patterns.
  • Rate limiting and account lockout mechanisms to mitigate brute-force attacks.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.