Try It Live

OctaBlitz is deployed and available at octablitz.alvinalmodal.dev. You can browse products, add items to cart, and go through the full checkout flow.


URL	octablitz.alvinalmodal.dev
Customer	`test-customer@octablitz.local` / `TestPass123`

This is a demo environment. Stripe and PayPal are in test/sandbox mode. No real charges will be made.

The Challenge

Building an ecommerce platform that actually works end-to-end is harder than it looks. Product catalogs, shopping carts, payment integrations, order management, inventory tracking, authentication, and deployment all need to work together reliably. Most tutorial-level ecommerce projects skip the hard parts: real payment providers, proper cart persistence across sessions, order status management, and production deployment with CI/CD.

I wanted to build the whole thing properly.

What I Built

OctaBlitz is a PC and gaming megastore built with .NET 10 and Angular 21. It covers the complete ecommerce lifecycle from browsing products to placing orders and processing payments through Stripe and PayPal.

How It Works

The backend follows clean architecture with five projects: API, Application, Domain, Infrastructure, and a shared contracts layer. Each use case gets its own service class instead of fat service classes that do everything. The Application layer defines the business logic, the Domain layer holds entities and interfaces, and the Infrastructure layer implements the repositories, payment providers, and cache.

Product Catalog. 344 products across 33 categories with full-text search, sorting, and category filtering. Products support multiple images with reorderable galleries. Stock is tracked per product with low-stock threshold alerts via Redis pub/sub.

Shopping Cart. The cart uses a dual-mode approach. Guest users get a localStorage cart. When they log in, the guest cart merges with their server-side cart which is backed by Redis for fast reads. Cart state persists across sessions.

Payment Processing. Payments use a strategy pattern with three providers: Stripe hosted checkout for credit/debit cards, PayPal hosted checkout for PayPal accounts, and a stub provider for development testing. The hosted checkout approach means OctaBlitz never handles raw card data, keeping it out of PCI scope. Webhook handlers process payment confirmations and update order status.

Order Management. Orders follow a status machine: Pending, Paid, Processing, Shipped, Delivered, or Cancelled. Prices are captured at order time as snapshots so price changes do not affect existing orders. Admins can transition statuses and view all orders. Customers can view their order history and details.

Authentication. ASP.NET Core Identity with JWT bearer tokens and refresh token rotation. The refresh token is stored as an HttpOnly cookie. Angular runs an auto-refresh effect before the access token expires so the user never gets logged out mid-session.

Key Technical Decisions

Clean architecture without MediatR: Each use case is a single service class (CreateProductService, PlaceOrderService, etc.) injected via DI. Simpler than a full CQRS setup and easier to debug for a team of one.
Redis for cart and events: Avoids database roundtrips for cart operations. Redis pub/sub handles inventory events (low-stock alerts, order placed notifications) via background subscribers.
Hosted checkout for payments: Stripe and PayPal handle the sensitive payment form. OctaBlitz redirects to the provider and handles the callback. This eliminates PCI compliance scope entirely.
Strategy pattern for payment providers: Adding a new provider means implementing one interface. The stub provider lets you develop and test the full checkout flow without real credentials.
Cloudflare Tunnel for deployment: The DigitalOcean droplet has no public ports exposed. Cloudflare Tunnel handles TLS termination and routes traffic through the Cloudflare edge network.
GitHub Actions CI/CD: Tests run on every PR. On merge to main, Docker images build, push to GHCR, SSH into the droplet, pull the new images, and restart. Health check verifies the deployment.

Testing

The project has 46 backend tests (38 unit, 8 integration with Testcontainers), 10 Playwright E2E test suites covering the full checkout flow, and frontend component tests with Vitest. Pre-commit hooks enforce linting and test passes before any commit.

What I Learned

The hardest part of building a real ecommerce platform is not any single feature. It is getting all the features to work together reliably. Payment webhooks need to handle retries and duplicate events. Cart merges on login need to handle conflicts. Order status transitions need validation so you cannot ship a cancelled order. Each integration point is a potential failure mode, and testing the happy path is not enough. The Playwright E2E tests that cover the full checkout flow (add to cart, checkout, pay, confirm) caught more bugs than the unit tests did.