API key management in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Designing a scalable API key storage system

You need to design a system to store and validate API keys for millions of users in a microservices environment. Which architectural choice best supports fast validation and scalability?

A Send API keys to an external third-party service for validation on every request.

B Store API keys in a centralized relational database and query it synchronously for every request.

C Use a distributed in-memory cache (like Redis) to store API keys with TTL and validate keys from cache.

D Store API keys in local files on each microservice instance and read from disk on every request.

💡 Hint

Think about latency and load on the database when validating keys for every request.

Using a distributed in-memory cache like Redis allows fast lookups with low latency and supports scalability by reducing load on the database.

🧠 Conceptual

intermediate

API key rotation strategy

What is the best practice for rotating API keys to maintain security without disrupting service?

A Rotate keys only when a security breach is detected.

B Allow old keys to remain valid for a grace period while new keys are issued and accepted.

C Never revoke old keys to avoid any service disruption.

D Immediately revoke old keys and force all clients to update simultaneously.

💡 Hint

Consider how to avoid downtime during key rotation.

Allowing a grace period where both old and new keys are valid ensures smooth transition without service disruption.

❓ scaling

advanced

Handling API key validation under high load

Your API gateway validates API keys for millions of requests per second. Which approach best reduces latency and avoids bottlenecks?

A Use a local cache on each gateway instance with periodic synchronization from a central store.

B Send all validation requests to a single dedicated validation microservice.

C Validate API keys synchronously by querying the database for each request.

D Disable API key validation during peak load to improve throughput.

💡 Hint

Think about reducing network calls and avoiding single points of failure.

Using a local cache on each gateway instance reduces latency and avoids bottlenecks by minimizing calls to central storage.

❓ tradeoff

advanced

Choosing between API key length and usability

Longer API keys increase security but reduce usability. What is the best tradeoff approach?

A Use short keys (e.g., 8 characters) to maximize usability even if security is weaker.

B Use no API keys and rely only on IP whitelisting.

C Use very long keys (e.g., 256 characters) to maximize security regardless of usability.

D Use moderately long keys (e.g., 32 characters) combined with HTTPS and rate limiting.

💡 Hint

Consider balancing security and user experience.

Moderate key length with transport security and rate limiting balances security and usability effectively.

❓ estimation

expert

Estimating storage requirements for API keys

You expect 10 million active API keys, each 40 characters long. Each key record stores the key, user ID (8 bytes), creation timestamp (8 bytes), and status (1 byte). Estimate the approximate storage needed in gigabytes (GB) for all keys, assuming UTF-8 encoding (1 byte per character) and ignoring database overhead.

A Approximately 0.5 GB

B Approximately 2.0 GB

C Approximately 1.0 GB

D Approximately 4.0 GB

💡 Hint

Calculate total bytes per record and multiply by number of keys, then convert to GB (1 GB = 1,073,741,824 bytes).

Each key: 40 bytes (characters) + 8 bytes (user ID) + 8 bytes (timestamp) + 1 byte (status) = 57 bytes per record.
10 million keys × 57 bytes = 570 million bytes ≈ 543 MB ≈ 0.5 GB.