Katkat
Back

Design multi-tenant ingestion and processing platform

AmazonSoftware Engineer · Onsite
MediumSoftware EngineerOnsiteSystem Design

Last updated

This question tests the ability to design a multi-tenant data platform that ensures resource fairness, performance isolation, and cost attribution at scale.

Problem Statement

Design a multi-tenant data ingestion and processing platform that receives telemetry events from various enterprise customers. The system must ingest events, perform basic validation/transformation, and sink them into customer-specific storage buckets.

Requirements

  1. Functional Requirements:

    • Provide a unified ingestion API (HTTP/gRPC).
    • Support asynchronous processing to handle traffic spikes.
    • Route data to tenant-specific storage destinations (S3, RDS, or external webhooks).

  2. Non-Functional Requirements:

    • Isolation: Prevent one tenant from exhausting system resources (CPU/Memory/Network/IO) and impacting others ("Noisy Neighbor" problem).
    • Fairness: Ensure latency SLAs are met for all tenants, even during high volume for specific customers.
    • Cost Allocation: Provide mechanisms to attribute infrastructure costs (compute/storage) to individual tenants for billing purposes.
    • Scalability: Handle up to 100,000 requests per second across 1,000+ distinct tenants.

Expectations

  • Define the high-level architecture and data flow.
  • Propose a strategy for tenant identification and request routing.
  • Explain how you would implement rate limiting and resource quotas per tenant.
  • Describe the metadata storage schema for tenant configuration and billing metrics.
  • Detail how you would handle tenant-specific credentials and secrets safely.

Hints

Hint 1

Consider using an API Gateway or Sidecar proxy to implement per-tenant rate limiting and authentication at the ingestion entry point.

Hint 2

Decide whether to use a shared compute pool with logical isolation (like namespaces or queues) or dedicated compute instances per tenant, and weigh the trade-offs in resource utilization.

Hint 3

Think about how to use tags or headers to propagate tenant identifiers through the pipeline to enable downstream cost attribution and multi-tenant observability.

Follow-up questions

  • How would you handle a scenario where a tenant suddenly spikes to 10x their usual traffic without failing their requests or dropping others?
  • If some tenants require 'data residency' (e.g., data must stay in EU regions), how would your architecture change?
  • How would you approach testing for tenant isolation to ensure that a security vulnerability in one tenant's webhook doesn't expose another tenant's data?