API key management in Microservices - Scalability & System Analysis

Scalability Analysis - API key management

Growth Table: API Key Management at Different Scales

Users / Requests	100 Users	10K Users	1M Users	100M Users
API Requests per Second (RPS)	~50 RPS	~5,000 RPS	~500,000 RPS	~50,000,000 RPS
API Key Storage Size	~100 keys (KBs)	~10K keys (MBs)	~1M keys (GBs)	~100M keys (100s GBs)
Authentication Latency	<1 ms	~1-5 ms	~5-20 ms	20+ ms without optimization
Rate Limiting Complexity	Simple in-memory counters	Distributed counters needed	Sharded counters with caching	Global distributed rate limiting system
Security Measures	Basic encryption and logging	Enhanced encryption, audit logs	Advanced monitoring, anomaly detection	AI-based threat detection, automated key revocation

First Bottleneck

The first bottleneck is the database that stores API keys and usage data. At low scale, a single database instance can handle key lookups and updates. As traffic grows to thousands of requests per second, the database faces high read/write loads for authentication and rate limiting.

Without caching, each API request triggers a database read to validate the key and update usage counters, causing latency and throughput issues.

Scaling Solutions

• Caching: Use an in-memory cache (e.g., Redis) to store API key validation results and rate limit counters to reduce database load.
• Read Replicas: Add read replicas for the database to distribute read queries.
• Sharding: Partition API keys by user ID or key prefix to distribute data and load across multiple database instances.
• Horizontal Scaling: Add more authentication servers behind a load balancer to handle increased request volume.
• Rate Limiting: Implement distributed rate limiting using Redis or specialized services to handle counters efficiently.
• Security: Use encryption for stored keys, rotate keys regularly, and monitor usage patterns for anomalies.

Back-of-Envelope Cost Analysis

• At 10K users generating ~5,000 RPS, assuming each request requires 2 Redis operations (check + increment), Redis handles ~10,000 ops/sec, well within a single instance capacity.
• Database writes for usage logs can be batched or asynchronously processed to reduce load.
• Storage for 1M API keys with metadata (~1 KB per key) requires ~1 GB of storage.
• Network bandwidth depends on request size; assuming 1 KB per request, 500,000 RPS equals ~500 MB/s, requiring multiple servers and network interfaces.

Interview Tip

When discussing API key management scalability, start by explaining the key components: storage, authentication, rate limiting, and security. Then describe how load increases affect each component. Identify the database as the first bottleneck and propose caching and sharding as solutions. Discuss trade-offs like consistency vs. latency. Finally, mention monitoring and security as ongoing concerns.

Self Check Question

Question: Your database handles 1000 QPS for API key validation. Traffic grows 10x to 10,000 QPS. What do you do first and why?

Answer: Add a caching layer (e.g., Redis) to store API key validation results and rate limit counters. This reduces direct database reads and writes, lowering latency and increasing throughput before scaling the database.

Key Result

The database storing API keys and usage data is the first bottleneck as traffic grows; adding caching and sharding are key steps to scale API key management efficiently.

Practice

1. What is the primary purpose of API key management in microservices?

easy

A. To generate random data for APIs

B. To speed up API response times

C. To store user passwords securely

D. To control and monitor access to APIs

Solution

1. Step 1: Understand API key management role

   API key management is about controlling who can use APIs and tracking their usage.

2. Step 2: Identify the main goal

   The main goal is to secure APIs by controlling and monitoring access, not speeding up or storing passwords.

3. Final Answer:

   To control and monitor access to APIs -> Option D

4. Quick Check:

   API key management = Access control [OK]

Hint: API keys control who uses your API [OK]

Common Mistakes:

• Confusing API keys with password storage
• Thinking API keys improve speed
• Assuming API keys generate data

2. Which of the following is the correct way to represent an API key in a request header?

easy

A. Auth-Key: <API_KEY>

B. Authorization: Bearer <API_KEY>

C. API-Key: <API_KEY>

D. Key: <API_KEY>

Solution

1. Step 1: Review common API key header formats

   API keys are often sent in headers named API-Key or similar, but Authorization: Bearer is usually for tokens, not API keys.

2. Step 2: Identify the standard header for API keys

   API-Key is the widely accepted header for API keys, making API-Key: <API_KEY> correct.

3. Final Answer:

   API-Key: <API_KEY> -> Option C

4. Quick Check:

   API key header = API-Key [OK]

Hint: API keys use 'API-Key' header, not 'Authorization: Bearer' [OK]

Common Mistakes:

• Using 'Authorization: Bearer' for API keys
• Confusing header names
• Omitting the key value

3. Given this pseudocode for API key validation:

function validateKey(request) {
  key = request.headers['API-Key']
  if key is null or key not in validKeys:
    return 'Access Denied'
  else:
    return 'Access Granted'
}

What will be the output if the request has no 'API-Key' header?

medium

A. Access Denied

B. Error: Missing header

C. Access Granted

D. Access Pending

Solution

1. Step 1: Check header presence condition

   The code checks if the key is null or not in validKeys. If the header is missing, key is null.

2. Step 2: Determine the return value for missing key

   Since key is null, the condition is true, so the function returns 'Access Denied'.

3. Final Answer:

   Access Denied -> Option A

4. Quick Check:

   Missing key = Access Denied [OK]

Hint: No API-Key header means deny access [OK]

Common Mistakes:

• Assuming missing key grants access
• Expecting an error instead of denial
• Confusing 'null' with empty string

4. A developer wrote this code snippet to revoke an API key:

function revokeKey(key) {
  if key in activeKeys:
    activeKeys.remove(key)
  else:
    print('Key not found')
}

But the key is still accepted after revocation. What is the likely issue?

medium

A. The remove method does not delete keys properly

B. The key is not removed from the validKeys list used for validation

C. The function does not print 'Key revoked' message

D. The key is being re-added automatically elsewhere

Solution

1. Step 1: Understand key revocation logic

   The function removes the key from activeKeys, but validation likely checks validKeys.

2. Step 2: Identify mismatch in key storage

   If validation uses validKeys and revoke removes from activeKeys, the key remains valid.

3. Final Answer:

   The key is not removed from the validKeys list used for validation -> Option B

4. Quick Check:

   Revocation must remove key from validation list [OK]

Hint: Revoking must remove key from validation store [OK]

Common Mistakes:

• Removing key from wrong list
• Assuming print messages affect logic
• Ignoring other code re-adding keys

5. You need to design an API key management system for a microservices platform that supports millions of users. Which approach best balances security, scalability, and ease of revocation?

hard

A. Store API keys in a centralized database with caching and use short-lived keys with rotation

B. Embed API keys directly in client apps without server validation

C. Use a single global API key for all users to simplify management

D. Store API keys only in memory on each microservice without persistence

Solution

1. Step 1: Evaluate security and scalability needs

   Millions of users require scalable storage and fast validation. Centralized DB with caching supports this.

2. Step 2: Consider revocation and key rotation

   Short-lived keys with rotation improve security and allow easy revocation without downtime.

3. Step 3: Eliminate insecure or unscalable options

   Embedding keys in clients or using a single key is insecure; in-memory only storage lacks persistence and scalability.

4. Final Answer:

   Store API keys in a centralized database with caching and use short-lived keys with rotation -> Option A

5. Quick Check:

   Central DB + caching + rotation = secure & scalable [OK]

Hint: Use central DB with caching and rotate keys regularly [OK]

Common Mistakes:

• Using single global key for all users
• Not persisting keys for revocation
• Embedding keys insecurely in clients