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

SeniorPrefer not to say

May 2026

Summary

Adobe system design round for a software engineer role. One massive question that basically covered every layer of the stack, from browser to database. Felt like they were testing whether you could hold a lot of complexity in your head at once rather than go deep on any single piece.

Questions Asked (1)

Walk through how you would analyze and improve end-to-end latency for a web request that passes through a browser, CDN, load balancer, microservices, caches, databases, and third-party services. Cover how you'd model and decompose the latency, instrument both client and server, attribute delays to frontend vs backend, investigate tail latency outliers, propose optimizations at every layer, and define SLIs/SLOs. Include a concrete numeric example showing baseline and expected improvements.

System DesignProduct Analytics & MetricsTechnical Trade-offs

Author's notes

This question is basically six questions duct-taped together and I did not pace myself well.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by decomposing the request path into distinct segments and defining how you'd measure each (client-side RUM, server-side tracing, synthetic tests). Then walk through instrumentation, attribution, tail latency analysis, and layered optimizations, anchoring everything with a concrete numeric example that shows baseline vs. improved latency and how you'd set SLIs/SLOs.

Pro tip: Emphasize that you'd instrument first and optimize second—many engineers jump to fixes without data. Also, explicitly call out that tail latency (p95/p99) often dominates user experience and requires different techniques (hedged requests, timeouts, circuit breakers) than median latency.

1. Model and decompose the latency

Break the end-to-end path into segments (browser, CDN, LB, each microservice, cache, DB, third-party) and define a latency budget per segment. Use a waterfall model to visualize where time is spent.

2. Instrument client and server

Implement Real User Monitoring (RUM) with Navigation Timing API and Resource Timing API on the client, and distributed tracing (e.g., OpenTelemetry) with span propagation on the server. Ensure trace context flows through all services.

3. Attribute delays and investigate tail latency

Correlate client-side timings with server-side traces to attribute delays to frontend vs backend. Analyze p50, p95, p99 latencies; identify outliers via trace sampling and log analysis, looking for GC pauses, network retries, cache misses, or slow third-party calls.

4. Propose layered optimizations

Suggest optimizations at each layer: browser (caching, code splitting), CDN (edge caching, Brotli), LB (connection pooling, keep-alive), microservices (async I/O, batching), caches (Redis, TTL tuning), DB (indexing, read replicas), third-party (timeouts, circuit breakers).

5. Define SLIs/SLOs and quantify improvements

Define SLIs like p95 latency for key endpoints, error rate, and throughput. Set SLOs (e.g., p95 < 200ms). Provide a numeric example: baseline p95 = 800ms, after optimizations p95 = 300ms, with breakdown of savings per layer.

Key Points to Mention

Use of distributed tracing (OpenTelemetry, Jaeger) with trace context propagation across services.
Client-side RUM and synthetic monitoring to capture real user latency and separate network vs. server time.
Tail latency analysis: p95/p99, hedged requests, timeouts, and circuit breakers to mitigate outliers.
Caching strategies at multiple layers (CDN, application cache, database query cache) and cache invalidation.
Database optimizations: indexing, query optimization, read replicas, connection pooling.
Concrete numeric example: baseline 800ms p95, after optimizations 300ms p95, with breakdown (e.g., CDN saves 200ms, DB indexing saves 150ms, etc.).

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