Design scalable LRU cache and backtracking API

Read the full interview experience this question came from →

Quick Overview

Design scalable LRU cache and backtracking API evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Design scalable LRU cache and backtracking API

Company: Adyen

Role: Software Engineer

Category: System Design

Difficulty: hard

Interview Round: Technical Screen

Build two production-ready services: A) A thread-safe LRU caching service. Specify API, in-process concurrency control (e.g., fine-grained locks or lock-free techniques), eviction correctness under concurrent access, TTL/size limits, metrics, and observability. Discuss how you would scale it across multiple instances using Redis or sharding/consistent hashing, handle hot keys, replication/failover, backpressure, and data consistency. B) A compute-heavy find-transfer-combinations API that may receive spikes of requests. Describe stateless vs stateful design, avoiding shared mutable state in workers, per-request memory management, caching/precomputation strategies, request de-duplication, rate limiting, timeouts, idempotency, and horizontal scaling. Provide capacity estimates and a testing plan.

Overview: Design scalable LRU cache and backtracking API evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

Read the full Adyen Software Engineer interview experience this question came from

Adyen logo
Adyen
Jul 26, 2025
hardSoftware EngineerTechnical ScreenSystem Design
24
0

Design scalable LRU cache and backtracking API

System Design: Two Production-Ready Services

A) Thread-Safe LRU Caching Service

Design and describe a production-ready, in-process LRU cache that can also be deployed as a networked cache service.

Specify:

  1. API surface (in-process library and optional network endpoints): get/put/delete/computeIfAbsent, per-entry TTL, size limits, stats.
  2. Concurrency control inside a process (e.g., fine-grained locks, lock striping, or lock-free techniques). Ensure eviction is correct under concurrent access.
  3. TTL and capacity management (entry count limit, weighted by bytes, admission control).
  4. Metrics and observability (hits/misses, evictions, latencies, saturation, traces, logs, debug endpoints).
  5. Scaling across multiple instances:
    • Using Redis (or another remote cache): topology, client behavior, backpressure, failure handling.
    • Or client-side sharding with consistent hashing: hot key mitigation, replication/failover, rebalancing, consistency model.
  6. Handling hot keys, backpressure, and data consistency semantics (cache-aside/write-through, stale reads, idempotency of updates, CAS).

Provide concrete choices and trade-offs.

B) Compute-Heavy "Find Transfer Combinations" API

Design an API that computes transfer route combinations (e.g., finding valid paths across payment rails/providers with constraints), with potential traffic spikes.

Specify:

  1. Stateless vs. stateful design; avoid shared mutable state in workers and define per-request memory management.
  2. Caching and precomputation strategies; request de-duplication (in-process and cross-instance).
  3. Rate limiting, timeouts/deadlines, cancellation, idempotency.
  4. Horizontal scaling and autoscaling policies; synchronous vs. async job modes.
  5. Capacity estimates with clear assumptions and formulas.
  6. A testing plan covering correctness, performance, reliability, and operability.

Make any minimal, explicit assumptions needed so the design is concrete.

Clarifying Questions to Ask Guidance

  • Clarify users, core use cases, read/write patterns, scale, latency, availability, and data retention.
  • State explicit assumptions before making sizing or architecture decisions.
  • Prioritize the functional path first, then address reliability, security, observability, and rollout.

What a Strong Answer Covers Guidance

  • A scoped requirements summary with concrete non-goals and success metrics.
  • API, data model, architecture, consistency, capacity, and operations.
  • Reasoned trade-offs among simple and scalable designs, including bottlenecks and failure modes.
  • A validation, monitoring, migration, and launch plan appropriate for the risk level.

Follow-up Questions Guidance

  • What breaks first at 10x traffic or data volume?
  • How would you degrade gracefully during dependency failures?
  • What metrics and alerts would prove the design is healthy after launch?