Skip to main content

Shopping Cart Architecture

In this section, we'll explore the shopping cart feature in the Dometrain platform and learn why migrating it to a specialized database is a smart architectural decision.

Current Implementation​

The Dometrain API currently includes a complete shopping cart feature stored in our PostgreSQL database. The cart provides standard e-commerce functionality:

  • Add to cart: Students can add courses to their shopping cart
  • Remove from cart: Students can remove individual courses they no longer want
  • View cart: Students can retrieve their current cart contents
  • Clear cart: Students can empty their entire cart

The Shopping Flow​

Here's how the cart fits into the overall purchase flow:

  1. Browsing: Students browse available courses
  2. Cart management: Students add desired courses to their cart
  3. Checkout: The cart contents are used to create a payment session
  4. Payment: Students complete payment through the payment gateway
  5. Enrollment: Upon successful payment, students are automatically enrolled in their purchased courses

The cart acts as a temporary holding area for course selections before purchase, making it easy for students to build their learning path before committing to payment.

Why Migrate the Cart?​

While PostgreSQL handles our cart data perfectly well, there are several reasons why the shopping cart is an ideal candidate for migration to a different data store.

Scaling Characteristics​

Shopping cart data has unique scaling properties:

  • High read/write ratio: Carts are frequently updated as students browse and make decisions
  • Temporary by nature: Most cart data is short-lived, deleted after purchase or abandoned
  • Independent domain: Cart operations don't require joins with other domains (courses, students, etc.)
  • Exponential growth potential: With thousands of students and hundreds of courses, cart items can scale rapidly

Consider this scenario:

  • 10,000 active students
  • Average of 5 courses per cart
  • 50,000 cart items to manage

As your platform grows, this number increases exponentially, creating unnecessary load on your primary database.

Database Pressure​

Even though PostgreSQL is highly optimized and our cart queries use primary keys for fast lookups, storing cart data in our main database creates several concerns:

  1. Resource competition: Cart operations compete with critical business data (orders, enrollments, course management)
  2. Backup overhead: Short-lived cart data gets included in database backups despite being transient
  3. Connection pool usage: High-frequency cart updates consume database connections
  4. Indexing overhead: Maintaining indexes for temporary data that will soon be deleted

Domain Separation​

From a domain-driven design perspective, the shopping cart is a bounded context that doesn't need tight integration with our core business data. It's an excellent candidate for extraction into its own microservice with its own specialized data store.

The Migration Strategy​

We're going to migrate the shopping cart functionality to Azure Cosmos DB, a globally distributed, multi-model database service designed for high-performance, scalable applications.

Why Cosmos DB?​

Azure Cosmos DB is an ideal fit for shopping cart data because:

  • Elastic scalability: Automatically scales throughput up or down based on demand
  • Low latency: Single-digit millisecond response times for reads and writes
  • Global distribution: Can be replicated globally for users worldwide (important for future expansion)
  • Flexible schema: Document model fits the cart structure perfectly
  • Cost-effective for this workload: Pay only for the throughput you provision

Benefits of This Approach​

By migrating the cart to Cosmos DB, we achieve:

  1. Database isolation: Shopping cart operations won't impact our core business database
  2. Independent scaling: Scale cart storage independently based on actual usage
  3. Performance optimization: Use a database optimized for high-frequency read/write operations
  4. Architectural flexibility: Begin our journey toward microservices architecture
  5. Technology diversity: Learn to integrate multiple data stores in our application

What's Next​

In the following sections, we'll:

  1. Set up Azure Cosmos DB in our Aspire AppHost
  2. Create the cart container with appropriate settings
  3. Update our application code to use Cosmos DB
  4. Implement caching with Redis to further improve performance
  5. Test the new implementation

This migration will be our first step in evolving from a monolithic architecture toward a more distributed system, where each component uses the technology best suited for its needs.