API key management in Microservices - System Design Exercise

Design: API Key Management System

Design covers API key lifecycle management, validation, and usage tracking. Does not cover full user authentication or billing systems.

Functional Requirements

FR1: Allow developers to create, view, and revoke API keys

FR2: Support multiple API keys per developer account

FR3: Enforce usage limits per API key (rate limiting)

FR4: Provide secure storage and transmission of API keys

FR5: Allow API keys to be scoped with permissions (read, write, admin)

FR6: Support key expiration and renewal

FR7: Audit logs for key usage and management actions

FR8: Integrate with existing microservices for authentication

Non-Functional Requirements

NFR1: Handle up to 100,000 active API keys

NFR2: API key validation latency under 10ms (p99)

NFR3: System availability 99.9% uptime

NFR4: Secure storage compliant with industry best practices

NFR5: Support horizontal scaling for high request volumes

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway or Authentication Service

API Key Management Service

Database for storing keys and metadata

Cache for fast key validation

Rate Limiter component

Audit Logging Service

Notification system for key expiration alerts

Design Patterns

Token-based authentication

Rate limiting with token bucket or leaky bucket

Caching for low latency validation

Event-driven audit logging

Key rotation and expiration

Reference Architecture

 +-------------------+       +-----------------------+       +------------------+
 |                   |       |                       |       |                  |
 |  API Gateway /    | <---> |  API Key Management    | <---> |  Database (SQL/NoSQL) |
 |  Auth Service     |       |  Service               |       |                  |
 |                   |       |                       |       |                  |
 +-------------------+       +-----------------------+       +------------------+
          |                             |                               |
          |                             |                               |
          v                             v                               v
 +-------------------+       +-----------------------+       +------------------+
 |                   |       |                       |       |                  |
 |  Cache (Redis)    |       |  Rate Limiter         |       |  Audit Logging    |
 |                   |       |                       |       |  Service          |
 +-------------------+       +-----------------------+       +------------------+

Components

API Gateway / Auth Service

Nginx, Envoy, or custom microservice

Intercepts API requests, extracts API key, and forwards for validation

API Key Management Service

Spring Boot, Node.js, or Go microservice

Handles API key creation, revocation, permission assignment, and expiration

Database

PostgreSQL or MongoDB

Stores API keys, metadata, permissions, usage stats

Cache

Redis or Memcached

Caches active API keys and permissions for fast validation

Rate Limiter

Redis-based token bucket algorithm

Enforces usage limits per API key

Audit Logging Service

Elastic Stack or Kafka + storage

Records key usage and management actions for compliance

Notification System

Email/SMS service or webhook

Alerts developers about key expiration or suspicious activity

Request Flow

1. Client sends API request with API key in header

2. API Gateway extracts API key and queries Cache for key validity and permissions

3. If cache miss, API Gateway calls API Key Management Service to validate key from Database

4. API Key Management Service returns key status and permissions

5. API Gateway enforces rate limiting by consulting Rate Limiter

6. If key is valid and under limit, request is forwarded to target microservice

7. API Key usage and request metadata are sent asynchronously to Audit Logging Service

8. Developers can manage keys via API Key Management Service UI or API

Database Schema

Entities: - DeveloperAccount (id, name, email) - APIKey (id, developer_id FK, key_hash, permissions, created_at, expires_at, revoked boolean) - UsageRecord (id, api_key_id FK, timestamp, endpoint, success boolean) - AuditLog (id, api_key_id FK, action, timestamp, details) Relationships: - DeveloperAccount 1:N APIKey - APIKey 1:N UsageRecord - APIKey 1:N AuditLog

Scaling Discussion

Bottlenecks

Cache misses causing high latency key validation

Rate limiter becoming a bottleneck under high request volume

Database write load from usage and audit logs

API Key Management Service handling many concurrent management requests

Solutions

Increase cache size and use TTL to reduce misses; use distributed cache cluster

Shard rate limiter by API key or use local rate limiting with periodic sync

Use write-optimized storage for logs; batch writes and use asynchronous processing

Scale API Key Management Service horizontally with load balancer

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain how API keys provide secure, scoped access

Discuss caching to meet low latency validation

Describe rate limiting approach and why it's important

Highlight audit logging for security and compliance

Mention horizontal scaling and fault tolerance strategies

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