Skip to content

README.md

Latest commit

 

History

History
124 lines (99 loc) · 7.1 KB

README.md

File metadata and controls

124 lines (99 loc) · 7.1 KB
Raw

⚡ High-Performance E-Commerce Backend Engine

build

A high-performance, concurrent e-commerce backend system built as a university project for the Parallel Programming course. The system simulates a real-world online store stress-tested with 200 concurrent users while maintaining data integrity, thread safety, and optimal resource utilization.

🎯 Project Overview

The primary goal of this project is to apply advanced parallel and concurrent programming concepts to solve real-world non-functional challenges in e-commerce systems, including race conditions, resource exhaustion, and transaction consistency under heavy load.

🏗️ Architecture

The solution follows a Clean Architecture approach, separated into three main layers:

1. ECommerceEngine (API Layer)

The presentation and application layer responsible for handling HTTP requests and orchestrating business logic.

  • Controllers: RESTful API endpoints for products, orders, and inventory.
  • DTOs: Data Transfer Objects for clean request/response contracts.
  • Services: Core business logic and concurrent operations.
  • Interfaces: Abstractions for dependency injection and testability.
  • Authorization: Role-based access control.
  • DependencyInjection: Centralized DI container configuration.

2. ECommerceEngine.LoadBalancer (Load Distribution Layer)

Simulates request distribution across multiple server instances to prevent single-point bottlenecks and ensure horizontal scalability.

3. Infrastructure (Data & Cross-Cutting Layer)

Handles all data persistence, caching, and background processing.

  • Data: DbContext and database configurations.
  • Entities: Domain models (Products, Orders, Inventory).
  • Migrations: EF Core database migrations.
  • Caching: Distributed caching strategy (In-Memory / Redis-ready).
  • BackgroundJob: Background workers for batch processing and async tasks.
  • Extensions: Custom middleware and service extensions.

✅ Non-Functional Requirements Implemented

# Requirement Implementation
1 Concurrent Access & Data Integrity Thread-safe inventory modification using concurrent collections and atomic operations, preventing Race Conditions.
2 Resource Management & Capacity Control Semaphore-based throttling to limit concurrent operations and prevent resource exhaustion.
3 Asynchronous Queues Non-blocking task offloading for notifications and invoice generation using Channel<T> and background services.
4 Batch Processing Background jobs that process daily sales reports in optimized chunks for maximum throughput.
5 Load Distribution Simulated load balancer distributing incoming requests across multiple server instances with configurable strategies.
6 Distributed Caching Caching layer for high-demand products to reduce direct database queries and improve response times.
7 Concurrency Control Implementation of both Optimistic Locking (row versioning) and Pessimistic Locking for sensitive inventory updates.
8 Transaction Integrity (ACID) Composite transactions (payment + inventory update + order creation) that fully succeed or fully rollback, even under concurrent access.
9 Stress Testing Automated stress tests using k6 (JavaScript) simulating 200 concurrent users without data loss or system crash.
10 Benchmarking & Bottleneck Analysis Performance profiling comparing response times before and after optimization, identifying the primary bottleneck.

🛠️ Tech Stack

  • Language: C#
  • Framework: ASP.NET Core (.NET 9)
  • ORM: Entity Framework Core
  • Database: SQL Server
  • Architecture: Clean Architecture (API + Infrastructure + LoadBalancer)
  • Concurrency: Task, Parallel, SemaphoreSlim, Channel<T>, ConcurrentDictionary
  • Caching: IDistributedCache backed by Redis
  • Load Balancing: YARP reverse proxy (round-robin across three API instances)
  • Security: JWT Bearer authentication, salted password hashing (ASP.NET Core Identity PasswordHasher)
  • Stress Testing: k6 (JavaScript-based load testing)
  • Tools: Visual Studio, Postman, Git

📡 API Endpoints

Method Endpoint Description
POST /api/Auth/register Register a new user (returns a JWT)
POST /api/Auth/login Log in (returns a JWT)
GET /api/Product?pageNumber=1&pageSize=4 Paged product list
GET /api/Product/{id} Product details (cached)
POST /api/cart/add-to-cart Add a product to the current user's cart
GET /api/cart/get-cart-items Get the current user's cart
PUT /api/cart/update-items/{cartItemId} Change an item's quantity
DELETE /api/cart/delete-item/{cartItemId} Remove an item from the cart
POST /api/orders/checkout Checkout with optimistic locking (ACID transaction)
POST /api/orders/checkout-pessimistic Checkout with pessimistic locking (UPDLOCK)
GET /api/orders/get-order-history Order history for the current user

The daily sales report is produced by a background service (DailySalesBatchService), not an endpoint.

🚀 How to Run

Prerequisites: .NET 9 SDK, SQL Server, Docker (for Redis), and k6 for load testing.

  1. Set ConnectionStrings:DefaultConnection in ECommerceEngine/appsettings.json to your SQL Server instance.
  2. Create the database: 
    dotnet ef database update --project Infrastructure --startup-project ECommerceEngine
  3. Start Redis: 
    docker run -d -p 6379:6379 redis
  4. Start three API instances, each in its own terminal (the ports the load balancer expects): 
    dotnet run --project ECommerceEngine/ECommerceEngine.csproj --urls "http://localhost:5001"
dotnet run --project ECommerceEngine/ECommerceEngine.csproj --urls "http://localhost:5002"
dotnet run --project ECommerceEngine/ECommerceEngine.csproj --urls "http://localhost:5003"
  5. Start the load balancer, which distributes requests round-robin across the three instances: 
    dotnet run --project ECommerceEngine.LoadBalancer/ECommerceEngine.LoadBalancer.csproj --urls "http://localhost:5000"
  6. Open Swagger on any instance, e.g. http://localhost:5001/swagger, or send requests through the load balancer at http://localhost:5000.

🧪 Stress Testing & Benchmarking

The project includes automated stress test scripts located in the API layer:

  • stress-test.js: Simulates 200 concurrent users performing simultaneous read/write operations.
  • bottleneck.js: Identifies and profiles the primary performance bottleneck in the system.

Running Stress Tests

Set BASE_URL at the top of each script to a single instance or to the load balancer, then:

cd ECommerceEngine

# Run the stress test
k6 run stress-test.js

# Run the bottleneck analysis
k6 run bottleneck.js