How to Design Scalable and High-Performance Architecture?

Question

Hello, I have a use case described below in detail, need your suggestions for scalable and high-performance AWS architecture. I have shared my thoughts as well regarding the problem statements and need more expert opinions. TIA

**Problem statements:**
1. To scale millions of sales opportunities, I have a sales opportunities database (Postgres in AWS) with millions of customers, and the sales opportunities scoring model will work across several customer profiles that are being processed. The interpretation endpoint should be able to dynamically rank millions of customers and make that data available. So the client from the front end can query and apply a filter to pull sales opportunities that are over a certain score. For example, customers with a score of greater than 80.
2. What should be the architecture of the solution in AWS?
3. How should be the solution GUI with the JavaScript UI APIs that efficiently interact with AWS?
4. How I can respond from the front-end application when sales opportunity quality is not good based on the customer feedback and have to adjust the sales opportunities scoring model for improvement?

**Following are my thoughts regarding the use case (problem statements) described above:**
1. Database sharding in AWS with PostgreSQL can be implemented using various techniques, in this case could be range-based (splitting data by score). Set up multiple **Amazon RDS** (Relational Database Service) instances as shard nodes. Each instance will represent a shard of the database. AWS Auto Scaling can help adjust the capacity of RDS instances based on demand.
To migrate existing data into shards we can use Amazon Database Migration Service (DMS).
2. Implement a routing layer that sits between my application and the database shards. This layer is responsible for routing queries to the appropriate shard. We can use **Amazon API Gateway**, to build this routing layer and it will act as the load balancer.
We can build routing logic by hashing or parsing query parameters to identify the correct shard. Here we should care about whether the queries that involve multiple shards (e.g., joins across shards) are handled efficiently.
3. We can create a distributed caching layer (e.g., **Amazon ElastiCache**) to improve query performance across shards and cache frequent query data.
4. We can use **AWS Lambda** for handling dynamic sales opportunities scoring and making the data available for front-end queries.
5. To interface with JavaScript UI, expose sales opportunities API(s) as RESTful endpoints. For this purpose, we can use **AWS SageMaker Endpoint**.
6. Analyze the feedback to identify areas for sales opportunities scoring model improvement. Make adjustments to the model based on feedback and retrain machine learning models if applicable.
To achieve this (CI/CD) we can use **AWS CodePipeline** and **AWS Codebuild** services.

**Your suggestions:**
Please advise what is missing or using unnecessary tools and how we can design more scalable, high-performance, and cost-effective architecture.

It would be great if you share or have some references for the Architecture diagram.

Thanks,

Emmanuela Opurum · Answer

Your thinking is largely on the right track. Here are the gaps and refinements worth considering.
On the database layer:
Database sharding via multiple RDS instances adds significant operational overhead for this use case. A more scalable and cost-effective approach is to keep a single Amazon Aurora PostgreSQL instance with read replicas for query scaling. Aurora auto-scales storage automatically and handles millions of rows well with proper indexing on your score column.
If you genuinely need sharding at scale, Amazon Aurora Sharding via RDS Proxy is cleaner than managing shard nodes manually.

**On scoring and ranking:**
Running the scoring model directly in Lambda works for lightweight models but will hit timeout and memory limits at millions of records. A better pattern is:

Run batch scoring on a schedule using AWS Batch or SageMaker Batch Transform
Write scored results into a dedicated DynamoDB table or ElastiCache (Redis) keyed by customer ID with score as an attribute
Front-end queries hit the cache not the database, giving you sub-millisecond reads at scale

**On the API layer:**
Replace the SageMaker endpoint for front-end queries, ageMaker endpoints are for model inference, not data retrieval. Use API Gateway backed by Lambda to query your pre-scored results from DynamoDB or ElastiCache instead.
On feedback and model retraining:
Your CI/CD approach with CodePipeline and CodeBuild is correct. Add Amazon SageMaker Pipelines for the ML retraining loop specifically, it handles data versioning, model versioning, and automated retraining triggers more cleanly than CodeBuild alone.

**Revised architecture summary:**
Aurora PostgreSQL → SageMaker Batch Transform (daily scoring) → DynamoDB or ElastiCache (scored results) → API Gateway + Lambda (front-end queries) → SageMaker Pipelines (feedback and retraining loop)

**Reference:**
**Amazon Aurora scaling:**
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html

**SageMaker Batch Transform:**
https://docs.aws.amazon.com/sagemaker/latest/dg/batch-transform.html

**DynamoDB for high-performance reads:**
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

**SageMaker Pipelines:**
https://docs.aws.amazon.com/sagemaker/latest/dg/pipelines.html

How to Design Scalable and High-Performance Architecture?

Add your answer

Relevant content