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

Senior

May 2026

Summary

Amazon system design round for a software engineering role. The whole thing was basically one big open-ended question about building a telemetry pipeline at massive scale, and they kept pushing on tradeoffs the entire time.

Questions Asked (1)

Design a distributed telemetry ingestion system that handles millions of devices and supports both real-time analytics (dashboards, alerts) and batch analytics (historical queries, aggregates, offline jobs). Cover ingestion protocols, auth, buffering, storage for hot vs cold data, stream vs batch processing, schema and partitioning, scalability, reliability, cost, and the core APIs you'd expose.

System DesignTechnical Trade-offsData Modeling

Author's notes

This one sprawled in every direction and I kept second-guessing where to anchor it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (scale, latency, data retention, query patterns) and then propose a high-level architecture that separates ingestion, stream processing, and storage layers. Dive into key components like ingestion protocols, buffering with Kafka/Kinesis, hot storage (e.g., DynamoDB, Redis) vs cold storage (S3, Redshift), and processing with Flink/Spark. Discuss trade-offs around consistency, cost, and scalability, and wrap up with API design and reliability mechanisms.

Pro tip: Emphasize decoupling and backpressure handling: use a durable buffer like Kafka to absorb spikes and enable multiple consumers. Also, mention how you'd handle schema evolution and ensure exactly-once semantics in stream processing, as these are common pitfalls in telemetry systems.

1. Clarify Requirements and Scope

Ask questions to understand scale (devices, messages/sec, data volume), latency requirements (real-time vs batch), data retention, query patterns, and consistency needs. This ensures the design meets actual needs.

2. High-Level Architecture

Outline the main components: ingestion endpoints, message queue, stream processing, storage layers (hot and cold), and query/analytics services. Explain data flow from devices to dashboards and batch jobs.

3. Deep Dive into Key Components

Detail ingestion protocols (HTTP, MQTT, gRPC), auth (API keys, OAuth, mTLS), buffering (Kafka/Kinesis), storage choices (time-series DB, S3, Redshift), and processing frameworks (Flink, Spark). Discuss partitioning and schema management.

4. Address Scalability, Reliability, and Cost

Explain how to scale each layer (horizontal scaling, sharding), ensure reliability (replication, fault tolerance, exactly-once processing), and optimize cost (tiered storage, compression, spot instances).

5. Define Core APIs and Trade-offs

Propose APIs for ingestion, querying, and management. Summarize key trade-offs (e.g., latency vs cost, consistency vs availability) and justify your choices.

Key Points to Mention

Ingestion protocols: support multiple protocols (HTTP/2, MQTT, gRPC) with authentication (API keys, OAuth, mTLS) and rate limiting.
Buffering and stream processing: use Kafka/Kinesis for durable buffering, and Flink/Spark Streaming for real-time processing with exactly-once semantics.
Storage tiering: hot storage (e.g., DynamoDB, Redis, time-series DB) for low-latency queries, cold storage (S3, Parquet) for cost-effective batch analytics.
Schema and partitioning: use a schema registry (Avro/Protobuf) for evolution, partition by time and device ID for efficient queries and scalability.
Scalability and reliability: design for horizontal scaling, replication, backpressure, and fault tolerance; consider multi-region deployment.
Cost optimization: use compression, tiered storage, and spot instances for batch processing; monitor and auto-scale resources.

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