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

SeniorPrefer not to say

Jun 2026

Summary

Google system design round for a software engineer role. The whole thing was one big question about building a key management service, and it went deep fast. Lots of follow-ups on things I hadn't fully thought through.

Questions Asked (1)

Design a key management service where clients request key material by providing a key ID. Cover the APIs, how keys are generated and stored, access control, auditing, rotation, usage limits, and your security and threat model. Also address latency, availability, and what happens if a key or system component gets compromised.

System DesignTechnical Trade-offsAPI & Integrations

Author's notes

I started with the API surface and storage, which felt natural, but the interviewer kept pushing on the threat model before I'd even finished the basic design.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and scale, then design a secure, highly available KMS with clear APIs, robust key lifecycle management, and defense-in-depth. Structure your answer around core components: key generation/storage, access control, auditing, rotation, and threat model, while addressing latency, availability, and compromise scenarios.

Pro tip: Emphasize that key material never leaves the KMS in plaintext, and use envelope encryption to minimize exposure. Also, discuss how you'd handle key compromise with automated rotation and revocation, showing you think about operational security.

1. Clarify Requirements and Scale

Ask about expected QPS, key types (symmetric/asymmetric), compliance needs (e.g., FIPS 140-2), and multi-region requirements to scope the design.

2. Design Core APIs and Data Model

Define APIs for key creation, retrieval (encrypt/decrypt), rotation, and revocation. Specify that clients request key material by key ID, but keys are used within KMS for crypto operations to avoid exposure.

3. Address Security and Access Control

Implement strong authentication (mTLS, IAM), fine-grained authorization (ACLs, RBAC), and audit logging for all key operations. Use HSMs for key storage and envelope encryption for data.

4. Cover Key Lifecycle and Rotation

Describe automatic rotation policies, versioning, and usage limits (e.g., max operations per key). Ensure old versions remain for decryption but not encryption.

5. Discuss Availability, Latency, and Compromise

Design for low latency with caching and geo-replication. Plan for key compromise with automated revocation, re-encryption, and blast radius minimization.

Key Points to Mention

Use of Hardware Security Modules (HSMs) for key generation and storage to ensure keys never leave secure hardware.
Envelope encryption: data encrypted with data keys, which are encrypted with master keys in KMS.
Access control with IAM policies, mTLS, and least privilege; audit logs for all key usage.
Key rotation: automatic periodic rotation, versioning, and re-encryption strategies.
Usage limits: rate limiting, quotas, and key usage policies to prevent abuse.
Threat model: insider threats, compromised clients, key exfiltration, and mitigation like key revocation and re-keying.

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