Api and Data Structure Design Questions

Focuses on designing efficient data models and public interfaces that back real world backend features, and selecting or inventing data structures to meet functional and non functional requirements. Candidates should be able to design data structures and classes to support use cases such as rate limiters, leaderboards, session managers, cache layers, analytics counters, and queueing or aggregation services. Topics include mapping operations to data structure choices for latency and throughput goals, persistence and eviction strategies for cached state, concurrency control and atomic operations, synchronization or lock free designs, partitioning and sharding implications, and tradeoffs between in memory, persisted, and distributed storage. Also cover API design considerations such as endpoint and payload design, versioning, pagination, idempotency, error handling, security and authentication, monitoring and observability, and how API shape influences internal data models and query patterns. Interviewers may ask candidates to produce class or interface sketches, data schemas, and rationale for chosen approaches and complexity characteristics.

MediumTechnical

54 practiced

Design the API contract and server-side behavior for a batch ingestion endpoint that accepts up to N events in a single HTTP request where partial failures are possible. How do you structure the request/response to report per-item success/failure, support retries and idempotency, and avoid excessive client-side complexity?

Sample Answer

Situation: We're designing a reliable batch ingestion endpoint for an SRE context where partial failures may occur and clients should be able to retry without complex logic.

API contract (JSON over HTTPS)- POST /v1/events: Accepts up to N items (configurable)- Headers: Authorization, Idempotency-Key (optional for whole-batch)- Body:{ "items": [ {"client_event_id":"uuid-1","payload":{...}}, {"client_event_id":"uuid-2","payload":{...}} ]}

Server-side behavior & idempotency- Primary idempotency: server honors per-item client_event_id (recommended). If missing, server uses per-batch Idempotency-Key + index as fallback.- Maintain an idempotency store (key -> result) with TTL (e.g., 24h) and bounded size; store final status and any assigned server_event_id.- On receive: validate all items syntactically; accept up to N and reject >N with 413 and clear message.

Response structure (always 200 for partial acceptance unless whole-batch invalid){ "batch_id":"server-batch-123", "results":[ {"client_event_id":"uuid-1","status":"success","server_event_id":"s-1"}, {"client_event_id":"uuid-2","status":"retryable_error","code":"TEMP_RATE_LIMIT","retry_after":30}, {"client_event_id":"uuid-3","status":"fatal_error","code":"INVALID_SCHEMA","message":"field X missing"} ], "retryable": true/false}

Status semantics- success: persisted/acked- retryable_error: transient (rate limit, downstream timeout) with suggested Retry-After; safe to retry entire batch or specific items- fatal_error: permanent; client should not retry that item

Retry & client complexity- Clients MAY retry entire batch with same client_event_id values; server deduplicates using idempotency store, returning previously recorded results.- To minimize client work, support whole-batch Idempotency-Key so clients can re-POST the same body and receive identical per-item results.- Provide a GET /v1/events/status?batch_id=... for polling if needed.

HTTP semantics- 200 OK: processed with per-item statuses- 400 Bad Request: malformed batch (no per-item results)- 413 Payload Too Large: >N items- 429/503: only for global capacity rejection (encourage client to back off)

Operational considerations- Differentiate transient vs permanent errors in logs/metrics; emit metrics: batch_success_rate, per-item_retry_rate, dedup_rate.- SLOs: target max per-item processing latency, and bounded idempotency TTL.- Backpressure: use per-client quotas and rate-limiting with explicit Retry-After.

Example flow- Client sends 5 items with client_event_id; server persists 3, returns retryable for 2 with Retry-After=20.- Client retries same POST after 25s; server returns success for previously-accepted items (from idempotency store) and reprocesses or accepts the two transient items.

This design keeps client logic simple (retry whole batch), ensures safe deduplication, reports per-item outcomes clearly, and gives SRE control over storage, TTL, and observability.

MediumSystem Design

43 practiced

Design a leaderboard service for a multiplayer game. Requirements: ~1k updates/sec, ~100k reads/sec, regional top-K queries, global rank queries, and soft real-time rank propagation (~1s). Provide API endpoints (submitScore, getTopK, getRank), data model choices (sorted sets, DB schema), caching strategy, sharding approach, and how you'll handle hot players and reconciliation between regional and global views.

Sample Answer

Requirements & constraints:- Writes: ~1k/sec, Reads: ~100k/sec, regional top-K, global rank, ~1s propagation (soft real-time), high availability.

APIs:- POST /submitScore {playerId, score, region, timestamp} → 202 Accepted- GET /topK?region={r}&k={K} → list of (playerId, score, rank)- GET /rank?playerId={id}&scope={region|global} → {rank, score}- Health/metrics endpoints for SRE

Data model:- Primary store: persistent DB (e.g., sharded PostgreSQL or DynamoDB) for authoritative player profile and score history.- In-memory sorted sets for real-time leaderboard: Redis Sorted Sets (ZADD/ZINCRBY/ZREVRANK/ZREVRANGE) per region + global.

Sharding:- Region-first: maintain one Redis sorted set per (region). Global leaderboard aggregated from regional deltas.- Partition players by playerId hash across Redis clusters to distribute update load. Each cluster holds many region-sorted-sets sharded by region+hash range.- Persistent DB sharded by playerId.

Caching strategy:- Serve top-K from Redis sorted sets (fast). Cache API responses with short TTL (~500ms–1s) for hot queries via CDN/edge caches where applicable.- Use read-through cache for rank queries; fallback to DB for cold players.

Update flow & propagation:1. Client -> submitScore API (load balanced, validated).2. Leader service writes to persistent DB (async, write-ahead queue) and enqueues update to a streaming layer (Kafka).3. Real-time workers consume Kafka, update regional Redis sorted set (ZADD) and publish delta to a global aggregator.4. Global aggregator periodically (every 500–1000ms) merges deltas into global Redis sorted set.

Handling hot players:- Detect hot players via metrics (high read rate). Pin hot players' data to memory-heavy Redis instances (vertical scale or dedicated shard).- Employ request-rate limiting and per-player caching; serve stale-but-fast responses when necessary.- Use fallback queues to smooth bursts: writes buffered in Kafka; workers autoscale.

Reconciliation & consistency:- Eventually consistent: Redis is primary for reads; DB is authoritative. Periodic reconciliation job (e.g., every minute) that scans DB top N per region and reconciles with Redis to correct drift.- On critical discrepancy (alert threshold), trigger immediate repair and replay Kafka logs for that player/region.- Use monotonic sequence numbers per player update to avoid out-of-order writes.

Reliability & SRE considerations:- SLOs: 99.9% availability, 95th latency for getTopK <50ms.- Monitoring: metrics for Redis latency, Kafka lag, worker errors, submitScore success/failure rates. Alerts on Kafka consumer lag > 1s, Redis OOM, reconciliation diff rate.- Autoscaling: consumers and Redis clusters scale based on metrics; use circuit-breakers to shed load under overload.- Backups: periodic snapshots of Redis + persistent DB backups; disaster recovery playbooks.

Trade-offs:- Using Redis gives low latency at cost of eventual consistency and memory usage. Periodic reconciliation and authoritative DB mitigate drift.- Aggregating global leaderboard every 1s balances freshness vs. cost.

EasyTechnical

50 practiced

Design a small, consistent JSON error response schema for public SRE-facing REST APIs that helps clients and observability. Include fields you would include (e.g., code, message, retryable, correlation_id, details), example response, and explain how this format helps client error handling and monitoring while avoiding leaking internal details.

Sample Answer

I propose a compact, consistent JSON error schema focused on client handling and SRE observability while withholding internal details:

Fields- timestamp: ISO8601 UTC time of error occurrence- correlation_id: request id propagated for tracing (string)- code: stable machine-readable error code (e.g., AUTH_EXPIRED, QUOTA_EXCEEDED)- status: HTTP status integer- message: short, user-facing description (safe to show to customers)- retryable: boolean (true if client should retry)- details: optional structured hints (key/value) for clients (non-sensitive)- meta: optional metadata (eg. region, shard) limited to non-secrets- docs_url: link to human-readable troubleshooting guidance

Example

json

{
  "timestamp": "2025-12-06T14:22:31Z",
  "correlation_id": "req-8f3a2b7c",
  "code": "QUOTA_EXCEEDED",
  "status": 429,
  "message": "Request quota exceeded for project",
  "retryable": true,
  "details": {
    "quota_limit": 1000,
    "reset_in_seconds": 3600
  },
  "meta": {
    "region": "us-east-1"
  },
  "docs_url": "https://api.example.com/docs/errors#QUOTA_EXCEEDED"
}

Why this helps- Clients: can programmatically branch on code/retryable and present clear UX using message/docs_url.- SRE/observability: correlation_id + timestamp + code enable log aggregation, tracing, alerts and SLO calculations without parsing free text.- Security: keep message generic, place actionable non-sensitive info in details/meta, and never expose stack traces, DB IDs, or internal hostnames.- Extensibility: codes are stable contract; details/meta allow adding helpful context without breaking clients.

EasyTechnical

39 practiced

Implement a thread-safe in-memory counter class in Go with methods: Increment(key string), Get(key string) int64, and Reset(key string). The implementation must be safe for concurrent goroutines. Sketch code or an interface, explain time complexity of operations, and discuss race conditions and a scaling approach for high cardinality.

Sample Answer

Use a sharded map of sync.Mutex-protected buckets and atomics for per-key counters to minimize global contention. Each bucket holds a map[string]*int64; Increment uses atomic.AddInt64 on the pointer. Reset replaces the pointer under the bucket lock.

package counters

import (
	"sync"
	"sync/atomic"
)

type shard struct {
	mu sync.RWMutex
	m  map[string]*int64
}

type Counter struct {
	shards []shard
	mask   uint64
}

func NewCounter(shardCount int) *Counter {
	if shardCount&(shardCount-1) != 0 {
		// force power of two for mask
		shardCount = 1 << uint(64-uint64(len(string(shardCount))))) // simplified; pick pow2 in real code
	}
	c := &Counter{shards: make([]shard, shardCount), mask: uint64(shardCount - 1)}
	for i := range c.shards {
		c.shards[i].m = make(map[string]*int64)
	}
	return c
}

func (c *Counter) shardFor(key string) *shard {
	h := fnv32a(key)
	return &c.shards[uint(h)&uint(c.mask)]
}

func (c *Counter) Increment(key string) {
	s := c.shardFor(key)
	s.mu.RLock()
	p, ok := s.m[key]
	s.mu.RUnlock()
	if !ok {
		s.mu.Lock()
		// double-check
		p, ok = s.m[key]
		if !ok {
			var v int64
			p = &v
			s.m[key] = p
		}
		s.mu.Unlock()
	}
	atomic.AddInt64(p, 1)
}

func (c *Counter) Get(key string) int64 {
	s := c.shardFor(key)
	s.mu.RLock()
	p := s.m[key]
	s.mu.RUnlock()
	if p == nil {
		return 0
	}
	return atomic.LoadInt64(p)
}

func (c *Counter) Reset(key string) {
	s := c.shardFor(key)
	s.mu.Lock()
	defer s.mu.Unlock()
	var v int64
	s.m[key] = &v
}

// simple FNV-1a
func fnv32a(s string) uint32 {
	const (
		offset = 2166136261
		prime  = 16777619
	)
	hash := uint32(offset)
	for i := 0; i < len(s); i++ {
		hash ^= uint32(s[i])
		hash *= prime
	}
	return hash
}

Key points:- Increment/Get use atomics avoiding heavy locks on hot keys.- Sharding reduces contention: operations lock only a shard.Time complexity:- Average O(1) for Increment/Get/Reset (amortized map ops).Race conditions:- Double-checked creation prevents races when adding keys; all increments use atomic ops so no data races on values.Scaling for high cardinality:- Increase shard count, use metrics aggregation (local per-proc shards then periodic flush), or external stores (Redis, Bigtable) for enormous cardinalities. Consider TTL eviction and approximate counters (HyperLogLog, Count-Min Sketch) if exact counts not required.

EasyTechnical

47 practiced

Explain compare-and-swap (CAS) at a high level: what it does, how retry loops work around it, and when you would choose CAS-based lock-free approaches versus traditional locks. Describe the ABA problem and one common mitigation technique.

Unlock Full Question Bank

Get access to hundreds of Api and Data Structure Design interview questions and detailed answers.

Join thousands of developers preparing for their dream job.