A SaaS company is designing a real-time telemetry processing platform for autonomous utility grids. The platform must process streams of incoming sensor data, validate the data payloads, and store the validated data for downstream analytics. The engineering team wants to implement an architecture that adheres to the AWS design principles of 'loose coupling' and 'services, not servers' to minimize operational maintenance and prevent data loss during traffic spikes.
Which TWO architectural decisions should the team implement to align with these design principles? (Select TWO.)
- Ingest and queue the data streams using Amazon Simple Queue Service (Amazon SQS) queues between the ingestion and processing layers.Answer
- Deploy a serverless data processing pipeline using AWS Lambda functions that write results directly to Amazon DynamoDB.Answer
- CRun a unified monolithic application on a cluster of Amazon EC2 instances to handle ingestion, validation, and storage in a single deployment package.
- DConfigure the processing application components to communicate via direct, hardcoded IP addresses to minimize latency between systems.
- EManually adjust the instance type of a single Amazon EC2 application server to a larger size whenever incoming telemetry traffic increases.
Answer
Ingest and queue the data streams using Amazon Simple Queue Service (Amazon SQS) queues between the ingestion and processing layers, and deploy a serverless data processing pipeline using AWS Lambda functions that write results directly to Amazon DynamoDB.
The correct architecture uses Amazon SQS to queue messages, which ensures that the ingestion and processing components are loosely coupled and can scale or fail independently without losing data. Additionally, using AWS Lambda and Amazon DynamoDB leverages the 'services, not servers' principle, allowing the company to build and run applications without the operational burden of provisioning and managing virtual servers.
Step-by-Step Solution
Key Concept
AWS Cloud design principles focus on loose coupling (reducing interdependencies between components) and services, not servers (using managed/serverless offerings to minimize operational overhead).