Edge Case Identification and Testing Questions

Focuses on systematically finding, reasoning about, and testing edge and corner cases to ensure the correctness and robustness of algorithms and code. Candidates should demonstrate how they clarify ambiguous requirements, enumerate problematic inputs such as empty or null values, single element and duplicate scenarios, negative and out of range values, off by one and boundary conditions, integer overflow and underflow, and very large inputs and scaling limits. Emphasize test driven thinking by mentally testing examples while coding, writing two to three concrete test cases before or after implementation, and creating unit and integration tests that exercise boundary conditions. Cover advanced test approaches when relevant such as property based testing and fuzz testing, techniques for reproducing and debugging edge case failures, and how optimizations or algorithmic changes preserve correctness. Interviewers look for a structured method to enumerate cases, prioritize based on likelihood and severity, and clearly communicate assumptions and test coverage.

MediumTechnical

76 practiced

A backend service shows intermittent 500 errors at peak traffic. List the telemetry (logs, metrics, traces) and specific fields you would capture to reproduce and diagnose edge-case failures (e.g., payload size, headers, correlation id, GC pauses, DB slow queries). Propose tests to ensure logging and tracing remain performant under high load and do not leak PII.

Sample Answer

**Situation & goal**List concrete telemetry fields (logs, metrics, traces) to capture intermittent 500s and propose tests that verify logging/tracing remain performant and PII-safe under peak load.

**Logs — fields to capture**- timestamp (ISO8601), service, environment, version- correlation_id / request_id, parent_span_id- http_method, path, query_string (or hash), status_code, response_time_ms- request_size_bytes, response_size_bytes- headers (only whitelisted: User-Agent, X-Forwarded-For shortened), auth_present (bool)- payload_sample_hash or length, sanitized_payload_snippet (PII redacted)- stack_trace / exception_type / error_message_id- host, pod/node id, container id

**Metrics**- request_rate (rps) per endpoint, error_rate (5xx) per endpoint- p50/p95/p99 latency, backend/db/external call latencies- CPU%, memory%, thread_count, GC_pause_ms (p50/p99)- DB_pool_usage, DB_query_duration_histogram, cache_miss_rate- log_emitted_rate, tracing_span_rate, dropped_spans

**Traces**- full distributed trace with timings for http entry, DB, cache, external APIs- span attributes: correlation_id, route, user_id_hash, payload_size- sampled error traces with full stack and upstream/downstream IDs

**PII & sampling policy**- Never log raw sensitive fields; store deterministic hashes for identifiers- Sampling: 100% error traces, 1–5% success traces, adaptive sampling during incidents- Size cap logs and traces (e.g., 64KB), truncate long headers/body

**Tests to run**- Load test at peak+20% traffic verifying: no increased error log latency, tracing ingestion within SLA, CPU/memory stable- Chaos test: inject GC pauses/DB slow queries and assert captured GC_pause_ms, DB_query_duration and correlated traces- Privacy test: send requests containing PII and scan logs/traces for raw PII (automated regex checks)- Logging throughput test: generate high log volume and assert no log queue growth, and measured end-to-end logging latency < X ms- End-to-end trace integrity: synthetic transactions through services verify correlation_id preserved and spans complete

**Why this helps**These fields and tests provide the signal to reproduce timing/size/header edge-cases, link errors to infra events (GC, DB), and ensure observability itself scales and stays compliant.

HardSystem Design

72 practiced

Design tests and acceptance criteria to ensure strict tenant data isolation in a multi-tenant SaaS backend using a shared database. Include tests for tenant-scoped queries, role-based access checks, accidental cross-tenant joins, data export redaction, and privacy compliance (e.g., GDPR). Provide examples of negative tests that prove data cannot leak between tenants.

Sample Answer

**Clarify scope & constraints**- Shared relational DB (Postgres), single schema with tenant_id column; backend enforces tenant isolation; RBAC present; GDPR requirements (right-to-be-forgotten, export, breach detection).

**High-level approach**- Combine unit tests for service layer, integration tests hitting DB, and end-to-end tests for exports and compliance flows. Use test tenants (tenant_a, tenant_b), distinct users and roles.

**Core acceptance criteria**- Every API request returns only rows where tenant_id = request.tenant_id.- Role checks prevent cross-tenant privileged access.- Joins and background jobs never surface other tenants’ data.- Exports redact/omit foreign-tenant fields and honor deletions.- Deletion requests remove or pseudonymize per GDPR and record audit.

**Test categories & examples**

1) Tenant-scoped query tests (integration)- Seed: one row per tenant in users, orders.- Call GET /orders as tenant_a user.- Assert: only tenant_a rows returned; SQL executed contains WHERE tenant_id = X.Example negative test SQL assertion:

sql

-- test fails if no tenant filter
SELECT * FROM orders WHERE id = $1 AND tenant_id = $2;

(Assert executed query includes tenant_id parameter.)

2) Role-based access checks- Create admin_user_tenant_a and read_only_user_tenant_b.- Attempt cross-tenant admin action: POST /tenants/{tenant_b}/config as admin_user_tenant_a => 403.Negative test: same JWT but different tenant header => 403.

3) Accidental cross-tenant joins- Seed shared reference table (plans) and tenant-owned subscriptions.- Create test that runs complex join used in reports; verify tenant_id applied to tenant-owned table and results only include tenant rows.- Use DB-level test: enable statement logging in test env and assert no JOIN produces rows with other tenant_id.

4) Data export & redaction- Trigger CSV/JSON export for tenant_a containing PII and a foreign-key to analytics table with global data.- Acceptance: exported file contains only tenant_a data; sensitive fields either masked or omitted per policy.Negative: request export for tenant_b using tenant_a token => 403 and no file generated.

5) GDPR flows- Right-to-be-forgotten: issue deletion for user_x in tenant_a; assert personally identifying fields removed/pseudonymized, foreign keys intact, exports do not include PII.- Data portability: export contains only tenant data and metadata describing transformations.

**Testing techniques & automation**- Use test containers + isolated DB per CI job; use fixtures and SQL assertions (pg_stat_statements or query logging) to assert WHERE clauses exist.- Fuzz tests: random queries and attempts to inject tenant_id = NULL or override.- Negative tests: attempt SQL injection or craft requests changing tenant header -> must be rejected.- Periodic property-based tests that swap tenant IDs and assert isolation invariants hold.

**Monitoring & defenses**- DB row-level security (RLS) policy example: enforce tenant_id = current_setting('app.tenant')::uuid.- Audit logs for cross-tenant access attempts and alerts in CI if any test reveals leakage.

This test suite proves isolation by positive checks (correct data returned) and negative checks (explicit attempts to access other tenant data always fail).

MediumTechnical

73 practiced

Design idempotent semantics for a POST /payments endpoint where clients may retry due to timeouts. Explain the API contract (idempotency-key header semantics), storage of keys and results, garbage collection, and how to test idempotency under concurrent retries, partially-applied transactions, and crashed workers.

Sample Answer

**API contract (idempotency-key header)** - POST /payments requires header: Idempotency-Key: <client-generated-UUID/v4> (128-bit recommended). - First request with a key creates a single logical operation; subsequent requests with same key within TTL must return the same HTTP status and response body (or an error if initial failed). - If client sends a different body with same key, server returns 409 Conflict.

**Storage model** - Use a durable idempotency store (Postgres table or Redis+persistent backing). Table: idempotency_keys (key PK, user_id, request_hash, status, response_code, response_body, created_at, updated_at). - request_hash = SHA256(body + relevant headers) to detect body changes. - status values: IN_PROGRESS, COMPLETED, FAILED. - Payment operation performed in a DB transaction; record IN_PROGRESS before external effects, store final response and set COMPLETED only after commit of payment record and external service confirmation (or compensating record).

**Concurrency & locking** - Acquire row-level lock (SELECT ... FOR UPDATE) on idempotency_keys when key exists; if absent, insert IN_PROGRESS atomically (upsert). This serializes handlers for same key. - For distributed systems, use a short-lived distributed lock (Redis Redlock) to avoid double work if using non-transactional flows.

**Garbage collection** - Keep entries for a default TTL (e.g., 7 days) to allow replays; run periodic cleanup of keys older than TTL. - For IN_PROGRESS stale entries older than timeout (e.g., 5–15 min), mark FAILED or provide a reconciliation path to let clients retry or consult a recovery endpoint.

**Handling partially-applied transactions & crashed workers** - Only set COMPLETED after all side-effects are durably committed. - Use two-phase commit-ish pattern: persist intent + external call idempotency tokens. If worker crashes after external call but before marking COMPLETED, reconcile by querying payment provider with stored provider_tx_id to decide result; mark accordingly. - Store provider_tx_id and webhook confirmations to resolve ambiguity.

**Testing idempotency** - Concurrent retries: run load tests that fire N parallel identical requests with same Idempotency-Key; assert only one payment record created and all responses identical. - Partially-applied: simulate failure after external call but before marking COMPLETED (inject crash); verify on retry the system queries provider_tx_id and returns same result without double charge. - Crashed workers: kill process mid-request; simulate restart and retry; verify IN_PROGRESS timeout logic or reconciliation prevents duplicate effects. - Add property-based tests: randomize body changes with same key to assert 409 conflict.

This design ensures single-effect semantics for retried POST /payments while enabling practical cleanup and recovery.

HardSystem Design

86 practiced

Design a distributed system that guarantees idempotent processing of commands across services when messages may be delivered at-least-once. Specify storage model for idempotency keys, TTL/eviction strategy, concurrency control and fallback for key-store failures. Then design automated tests that simulate concurrent duplicate messages, partial commits, and key-store partition/failure, showing how system preserves correctness.

Sample Answer

**High-level approach**- Use an idempotency-key per command: e.g., client_id + command_id + optional resource_id. Keys are authoritative for deduplication.- Primary key-store: Redis (clustered) for low-latency SETNX + TTL. Persist final result (response or result pointer) so repeat requests can return cached response.- Secondary fallback: relational DB table with unique constraint (POSTGRES idempotency_keys) for durability when key-store fails.

Storage model- Redis entry structure: - Key: idempotency:{client}:{cmd} - Value: JSON { state: "INPROGRESS" | "DONE", owner: instance-id, result_ptr: <db_id|blob>, created_at, last_heartbeat } - Use SETNX to create INPROGRESS and EXPIRE to TTL.- Postgres table (fallback): - Columns: client, cmd, state, owner, result_ptr, updated_at - Unique index on (client, cmd).

TTL / eviction strategy- Short TTL for INPROGRESS (e.g., 60s) with heartbeat extension while processing.- When DONE, set longer TTL (e.g., 24h) to allow replay of responses, then eventually evict to save space.- Redis eviction: rely on EXPIRE; for cluster-wide eviction, run periodic sweep jobs to remove stale INPROGRESS older than a threshold and record as FAILED for reconciliation.

Concurrency control- Acquire lock via atomic Redis Lua script: - If key doesn't exist -> create INPROGRESS, set owner, expire -> allow processing. - If state == INPROGRESS and owner == self -> reentrant (restart after crash). - If state == DONE -> return cached result. - If INPROGRESS and owner != self -> fail fast / retry with backoff.- Use Redis EVAL to atomically check & set and read state+result.- On successful processing, write result to durable DB and then atomically set state= DONE and result_ptr in Redis (single Lua script).- Heartbeat: processing instance updates last_heartbeat periodically; other instances can claim if heartbeat stale (> heartbeat_timeout) using atomic claim via Lua that checks timestamp.

Fallback for key-store failures- If Redis unavailable: - Attempt to insert idempotency row in Postgres with unique constraint using transactional INSERT ... ON CONFLICT DO NOTHING. - If insert succeeds -> we own processing. - If conflict -> fetch state; if DONE -> return result; if INPROGRESS -> use optimistic retry/wait and rely on DB for reconciliation.- If both fail: reject with 503 and let upstream retry (safer than risking non-idempotent side-effects).

Failure modes and mitigation- Partial commit: always follow pattern: 1) Acquire idempotency key (INPROGRESS). 2) Perform processing and write all side-effecting changes inside DB transaction or to services with compensating actions. 3) Persist result pointer in DB. 4) Atomically mark idempotency key DONE with result_ptr.- This ensures either processing observed as not started (INPROGRESS missing or claimable) or fully DONE.

Automated tests- Test harness components: local message broker (Kafka or in-memory queue), Redis cluster (docker-compose), Postgres, Toxiproxy to simulate network partitions. Use pytest + asyncio for concurrency; use test doubles for downstream services.- Tests to implement:

1) Concurrent duplicate messages- Start N worker instances pointed at queue.- Push same command id K times.- Assert: only one processing action performed (use a counter service or DB row with unique transaction). Assert other attempts returned cached result or were rejected/short-circuited.- Tools: spawn workers as separate processes or threads; use barrier to ensure concurrent acquisition attempts.

2) Partial commits (crash during processing)- Simulate instance crash after performing side-effect but before marking DONE (kill process after DB write but before marking Redis DONE).- After crash, start a new worker processing same idempotency key.- Assert: system detects INPROGRESS stale, claims, checks DB for partial side-effect, reconciles (either idempotent retry or skip), and final state is consistent (no duplicate side-effect).- Validate using DB counts and idempotency row state.

3) Key-store partition/failure- Use Toxiproxy to drop Redis traffic for window T.- While Redis down, send duplicates; verify fallback to Postgres INSERT unique constraint allowed single owner to proceed and prevented duplicates.- Restore Redis: run background job to reconcile Postgres idempotency rows back into Redis (repopulate DONE entries).- Assert correctness: single side-effect, responses consistent.

Assertions and metrics- Side-effect counter remains == 1 per unique command.- Idempotency rows end in DONE with correct result_ptr.- No resource leaks: stale INPROGRESS reaped after timeout.- Latency and failure metrics: measure retry counts and error rates in failure scenarios.

Why this design- Redis provides low-latency dedupe and quick failure detection; Postgres provides durable fallback and strong uniqueness guarantees.- Atomic Lua scripts prevent race conditions on acquisition and marking DONE.- Heartbeats and TTLs limit lock staleness while allowing recovery.- Tests exercise concurrency, partial failures and partitioning to validate correctness under real-world failure modes.

MediumSystem Design

122 practiced

Design how to prevent duplicate orders in PostgreSQL when clients retry due to network errors. Discuss schema-level options (unique constraint on idempotency key), application-level idempotency keys, transactions and isolation levels. Describe integration test scenarios that reproduce duplicate creation under concurrent retries and how the system should recover.

Sample Answer

**Clarify goal**Prevent duplicate orders when clients retry (e.g., network timeouts) while keeping low latency and correctness under concurrency.

**Schema-level: unique idempotency key**- Add an idempotency_key column and unique constraint on (user_id, idempotency_key) or globally.- Optional: status columns (processing, completed) and created_at.

sql

-- schema
CREATE TABLE orders (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid NOT NULL,
  idempotency_key text,
  amount numeric NOT NULL,
  status text NOT NULL DEFAULT 'processing',
  created_at timestamptz DEFAULT now(),
  UNIQUE (user_id, idempotency_key)
);

**Application-level idempotency**- Client generates a stable idempotency key per logical request.- Server uses the key on first receipt to insert; on duplicates return existing resource.- Pattern: INSERT ... ON CONFLICT DO NOTHING then SELECT; or INSERT ... ON CONFLICT DO UPDATE to set id.

python

# sketch (psycopg)
with conn:
    cur.execute("INSERT INTO orders (user_id,idempotency_key,amount) VALUES (%s,%s,%s) ON CONFLICT (user_id,idempotency_key) DO NOTHING RETURNING id,status", (uid,key,amt))
    row = cur.fetchone()
    if row: return row
    cur.execute("SELECT id,status FROM orders WHERE user_id=%s AND idempotency_key=%s", (uid,key))
    return cur.fetchone()

**Transactions & isolation**- Unique constraint enforces correctness; use short transactions.- SERIALIZABLE not required; REPEATABLE READ/READ COMMITTED suffice when relying on constraint + ON CONFLICT.- Avoid long locks during external calls — complete DB insert first (mark processing), then call downstream services; use compensating actions on failure.

**Integration tests**- Concurrent retry test: spawn N concurrent requests with same idempotency_key; assert single order row created.- Partial-failure test: client times out after server returns but server eventually inserts — ensure retry returns existing order.- Race with different keys: ensure distinct keys create distinct orders.- Recovery test: insert created with status=processing, simulate crash, have a reaper job mark/stall and retry finalization; assert idempotent downstream calls.

**Why this design**- Unique constraint provides schema-level safety against races.- App-level idempotency gives semantics and proper client behavior.- Short transactions + ON CONFLICT keep performance and correctness.

Unlock Full Question Bank

Get access to hundreds of Edge Case Identification and Testing interview questions and detailed answers.

Join thousands of developers preparing for their dream job.