How do I approach System Design interview questions?

System Design questions require understanding of core concepts and practice. PracHub provides solutions with explanations to help you master system design interviews.

What difficulty level is this interview question?

This is a hard difficulty System Design question, commonly asked during Technical Screen rounds at Meta.

What role is this question designed for?

This question is commonly asked for Software Engineer candidates at Meta during technical interviews.

Handle invalid input at system level | Meta Interview Question

Quick Overview

This question evaluates a candidate's competency in designing end-to-end validation, error handling, and operability for a REST API, covering input schema validation, authentication and authorization, rate limiting, idempotency, error classification, partial-failure strategies, timeouts/retries, observability, and graceful degradation in the System Design domain. It is commonly asked to assess how candidates reason about building robust, production-grade services that handle malformed or oversized payloads and partial failures, and it tests practical application of system-level design principles rather than low-level algorithmic implementation.

Design: Validation and Error Handling for a Top-K Frequency API

Context

You are designing a REST endpoint that computes the top-K most frequent values from a client-provided array. The focus is on end-to-end validation, robustness, and operability rather than the counting algorithm itself.

Assume the endpoint is:

Method: POST
Path: /v1/topk
Purpose: Given an array of primitive values and an integer K, return the K most frequent values with counts.
Values may be strings or numbers; response ordering must be deterministic (by count desc, then value lexicographically).

Requirements

Design the validation and error-handling strategy covering:

Input schema validation (types, ranges, size limits, content-type, compression)
Authentication and authorization
Rate limiting and quotas
Idempotency for safe retries
Consistent error codes and messages (4xx vs 5xx)
Partial failures (e.g., invalid elements) and response strategy
Timeouts and retries (client and server), backoff guidance
Observability (structured logs, metrics, tracing)
Graceful degradation for oversized or malformed payloads (e.g., sampling or approximate results)
Provide example API contracts and sample error responses

Handle invalid input at system level

Quick Overview

Design: Validation and Error Handling for a Top-K Frequency API

Context

Requirements

Solution

Comments (0)