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

SeniorPrefer not to say

Apr 2026

Summary

Adobe system design round for a software engineering role. One question, but it was a beast. Spent the whole session on a single distributed ID generation problem and it kept branching into more sub-problems than I expected.

Questions Asked (1)

Design an API that returns a unique random integer from a range of 1 to 33 trillion, never repeating a value, at 300,000 requests per second. Walk through how you'd track issued numbers at scale, partition the keyspace across nodes, guarantee exactly-once issuance with durability, handle leader election, and then explain how you'd extend the design if the keyspace doubled.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I started with a bitmap and immediately got pushback on memory.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a partitioned, replicated service using a distributed counter or pre-allocated blocks to ensure uniqueness and exactly-once issuance. Walk through the architecture, covering partitioning, durability, leader election, and scaling, while discussing trade-offs and alternatives.

Pro tip: Emphasize that pre-allocating blocks of numbers to nodes drastically reduces coordination overhead and simplifies exactly-once semantics, but be ready to discuss the trade-off of potential gaps if a node fails.

1. Clarify Requirements and Constraints

Confirm the range (1 to 33 trillion), rate (300k QPS), uniqueness, durability, and exactly-once semantics. Discuss whether gaps are acceptable and the expected latency.

2. High-Level Architecture

Propose a partitioned service where each node owns a disjoint range of the keyspace. Use a distributed coordination service (e.g., ZooKeeper, etcd) for leader election and configuration.

3. Uniqueness and Exactly-Once Issuance

Use pre-allocated blocks: each node leases a block of numbers from a central allocator, then serves numbers from that block. Persist issued numbers or block leases to durable storage (e.g., write-ahead log, replicated database) before returning to client.

4. Partitioning and Scaling

Partition the keyspace using consistent hashing or range partitioning. For doubling the keyspace, re-partition or use a hierarchical allocation scheme (e.g., two-level counters) to avoid hotspots.

5. Fault Tolerance and Leader Election

Replicate each partition (e.g., Raft) for durability. Use leader election per partition to coordinate block allocation and ensure exactly-once. Handle node failures by reassigning blocks and ensuring no duplicates via idempotent operations.

Key Points to Mention

Partitioning strategies (range vs. hash) and their impact on uniqueness and scalability
Pre-allocation of number blocks to reduce coordination and enable high throughput
Durability mechanisms: write-ahead logging, replication, and consensus protocols (Raft/Paxos)
Exactly-once semantics via idempotent operations and transactional block allocation
Leader election using ZooKeeper/etcd and handling failover without duplicates
Scaling the keyspace: re-partitioning, hierarchical allocation, and avoiding hotspots

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