E-Commerce Catalog & Orders: Relational vs NoSQL Polyglot Persistence
Splitting an e-commerce platform between Aurora Serverless v2 for ACID order transactions and DynamoDB for ultra-low latency product catalog reads.
1. Business Problem & Context
An e-commerce retailer tried to store both product catalog browsing (read-heavy, unstructured attributes) and checkout orders (write-heavy, strict ACID, payment ledgers) inside a single standard PostgreSQL database. During flash sales, browsing traffic consumed 100% of PostgreSQL connection pools, causing checkout payments to fail.
2. Requirements & Constraints
- Catalog Throughput: Handle 50,000+ browsing queries/sec with sub-10ms latency.
- Payment Integrity: Guarantee zero double-charges or corrupted inventory tallies.
- Connection Protection: Prevent ephemeral serverless compute from overwhelming database connections.
3. Architecture Overview & Data Flow
Interactive Architecture Diagram (Use controls to zoom & pan)
4. AWS Services Used & Rationales
AWS Services Architecture Rationale
Concrete reasons why these specific services were chosen over alternatives
| Service | Category | Architectural Rationale ("Why this service?") |
|---|---|---|
| Amazon DynamoDB | Database | Chosen for the product catalog to support flexible JSON schema attributes and sub-5ms partition reads. |
| Amazon Aurora Serverless v2 | Database | Provides PostgreSQL ACID transactions and auto-scales compute (ACUs) in fractions of a second. |
| AWS RDS Proxy | Database | Shields Aurora from Lambda connection bursts by multiplexing thousands of client connections into a compact pool. |
5. Key Design Trade-offs
Architecture Decision & Trade-Off Matrix
Evaluating alternative approaches under real-world constraints
Single Monolithic Relational DB
- + Unified SQL queries
- + Single database to manage
- − Browsing traffic starves checkout transactions
- − Connection limits (max_connections) easily reached
Polyglot Persistence Split (Chosen)
✓ Chosen Design- + Independent scaling
- + Browsing traffic cannot crash checkout
- + Ultra-fast catalog latency
- − Requires dual data management and synchronization
6. Implementation Highlights
Architecture Guard Why RDS Proxy is Mandatory for Serverless RDBMS Access
Each AWS Lambda invocation container opens a dedicated database connection. If 1,000 Lambda functions spin up during a flash sale, opening 1,000 PostgreSQL connections will consume ~10GB of DB RAM just for connection memory, crashing the database engine.
AWS RDS Proxy sits between Lambda and Aurora, maintaining a pool of ~50 warm connections and multiplexing thousands of incoming Lambda queries across them seamlessly.
7. Results & Key Metrics
- Catalog Page Load: Improved from 140ms to 18ms.
- Checkout Failures: Dropped from 3.2% during flash sales to 0.00%.
8. Key Architectural Takeaways
Polyglot Rule: Use NoSQL (DynamoDB) where read velocity and flexible schemas dominate; use Relational (Aurora) where complex multi-table ACID transactions and financial guarantees are non-negotiable.
