Design a platform that lets developers collect end‑user feedback and control feature rollout to targeted cohorts. Define service boundaries, data flows, core classes, API endpoints (e.g., submitFeedback, listFeedback, createFlag, evaluateFlag), and database schemas. Address multi‑tenancy, authentication/authorization, rate limiting, moderation, analytics aggregation, privacy/PII handling, caching for real‑time flag evaluation, gradual rollouts (percentage and rule‑based), kill switches, audit logs, and safety/observability. Provide scaling estimates and consistency considerations.

This interview question evaluates requirements, scale assumptions, API/data design, architecture, trade-offs, failure modes, and rollout in a realistic interview setting. A strong answer for Design feedback and feature rollout platform states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.

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 Onsite rounds at Amazon.

What role is this question designed for?

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

Design feedback and feature rollout platform

System Design: Feedback + Feature Rollout Platform

Context

Build a multi-tenant platform that lets product teams:

Collect end-user feedback from applications.
Control feature rollout to targeted cohorts via feature flags.

Assume web/mobile SDKs, admin console, and public APIs. The platform should serve multiple tenants (organizations) and environments (dev/stage/prod).

Requirements

Functional

Feedback
- Submit end-user feedback (text, screenshots, metadata).
- List/search/filter feedback by tenant, app, environment, tags, status.
- Moderation workflow (auto + human review).
- Analytics aggregation (trends, NPS/CSAT, tags/topics).
Feature Flags
- Create/update/delete flags with variants and targeting rules.
- Evaluate flags in real time with caching for low latency.
- Gradual rollouts (percentage-based, rule/segment-based).
- Kill switches and safe defaults.
APIs and SDKs
- Endpoints such as submitFeedback, listFeedback, createFlag, evaluateFlag.
- Admin console for configuration and moderation.

Non-Functional

Multi-tenancy isolation, authn/z (RBAC), rate limiting.
Privacy/PII handling, data residency, encryption.
Audit logs, safety/observability, SLOs.
Scalability, cost efficiency, DR/BCP.
Consistency expectations and propagation SLAs.

Deliverables

Service boundaries and data flows.
Core classes/objects and database schemas.
API endpoints (with request/response fields).
Handling of multi-tenancy, authn/z, rate limiting, moderation, analytics, PII, caching, rollout strategies, kill switches, audit logs, safety/observability.
Scaling estimates and consistency considerations.

Constraints & Assumptions

Preserve the scope, facts, inputs, and requested outputs from the prompt above.
If the prompt leaves a detail unspecified, state a reasonable assumption before relying on it.
Keep the answer interview-ready: concise enough to present, but concrete enough to implement or evaluate.

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?