Vayzo Platform Blueprint¶

This page is the consolidated knowledge-base reference for the Vayzo multi-brand marketplace. It brings together the application architecture, technology/skillset, implemented marketplace capabilities, and the target CI/CD deployment flow.

The operating principle for Vayzo is automation first: normal releases should not require SSH sessions, hand-edited configuration, manually executed database migrations, or repeated browser-by-browser verification. Jenkins, Docker, Terraform, Kubernetes, Helm and automated tests provide the release path; production keeps a single explicit approval gate.

1. Platform architecture¶

Customers / Sellers / Administrators
                |
                v
+---------------------------------------------------------+
| Cloudflare                                              |
| DNS | TLS | CDN | WAF | edge protection                |
+-----------------------------+---------------------------+
                              |
                              v
+---------------------------------------------------------+
| Shared K3s / Kubernetes platform                        |
| Traefik Ingress                                         |
|                                                         |
|  +-------------------+       +-----------------------+  |
|  | Vayzo Frontend    | /api  | Vayzo Backend API     |  |
|  | React 18 + Vite   +------>| ASP.NET Core / .NET 8 |  |
|  | nginx             |       | Clean Architecture    |  |
|  +-------------------+       +----------+------------+  |
|                                         |               |
|                  +----------------------+------------+  |
|                  |                                   |  |
|          Kubernetes Job / worker               Health probes
|          migrations / scheduled work      live / ready checks
+------------------+----------------------+--------------------+
                   |                      |
                   v                      v
          +----------------+      +----------------+
          | MySQL 8.2      |      | Redis 7.2      |
          | transactional  |      | cache/runtime  |
          | marketplace DB |      | coordination   |
          +----------------+      +----------------+
                   |
                   | media / backups
                   v
          +----------------+
          | Cloudflare R2  |
          | object storage |
          +----------------+

External traffic model¶

The frontend nginx container is the single application entry point. Kubernetes Ingress sends public application traffic to the frontend Service; nginx proxies /api/* to the backend Service inside the cluster. The backend Service is not directly exposed through Ingress.

Application layers¶

ECommerce.Domain
      |
      v
ECommerce.Application
      |
      v
ECommerce.Infrastructure
      |
      v
ECommerce.API

Domain - entities, state machines, financial/inventory rules and domain exceptions.
Application - CQRS commands/queries, MediatR handlers, validation and orchestration.
Infrastructure - EF Core/Pomelo MySQL, repositories, Redis/storage/provider integrations.
API - controllers, authentication/authorization, middleware, rate limiting, health checks and runtime configuration.

Environment topology¶

Hetzner Cloud
|
+-- Shared K3s platform VM
|   +-- Traefik
|   +-- namespace: akshayabazaar-staging
|   |   +-- frontend pods
|   |   +-- backend pods
|   |   +-- migration jobs
|   +-- namespace: akshayabazaar-production
|       +-- frontend pods
|       +-- backend pods
|       +-- migration jobs
|
+-- Staging data VM
|   +-- MySQL
|   +-- Redis
|
+-- Production data VM
    +-- MySQL
    +-- Redis

Cloudflare
+-- environment DNS
+-- TLS / security controls
+-- staging media + backup R2 buckets
+-- production media + backup R2 buckets

Staging and production share the Kubernetes platform node but remain isolated by namespace, Kubernetes Secrets, database/Redis hosts and credentials, R2 buckets and environment configuration.

2. Technology and skillset¶

Area	Technology / Skill	Purpose in Vayzo
Backend	C#, .NET 8, ASP.NET Core	Marketplace APIs and business workflows
Architecture	Clean Architecture, DDD-style domain modelling	Separation of business rules from infrastructure
Application pattern	CQRS, MediatR, FluentValidation	Commands, queries and validation
Data access	EF Core 8, Pomelo	Persistence and migrations
Database	MySQL 8.2	Transactional marketplace and financial data
Cache/runtime	Redis 7.2	Runtime dependency and distributed coordination/cache use cases
Frontend	React 18, Vite	Customer, seller and admin web experiences
Client state	Redux Toolkit	Browser application state
Server state	TanStack React Query	API data/query lifecycle
Routing	React Router	Customer/seller/admin navigation
Styling	Tailwind CSS + application CSS	Responsive marketplace UI
HTTP	Axios	API access and authentication flows
Authentication	JWT access + refresh-token lifecycle	Secure user sessions
Security	RBAC, authorization, rate limiting, HSTS, CORS, security headers	Application protection
Password security	BCrypt	Password hashing
Payments	Razorpay	Checkout/payment verification; production provider activation remains a release gate
Object storage	Cloudflare R2	Images/media and infrastructure backup storage
Containers	Docker	Immutable application packaging
Container registry	GHCR	Versioned backend/frontend images
Orchestration	Kubernetes / K3s	Staging and production runtime
Ingress	Traefik	Cluster ingress and routing
Kubernetes packaging	Helm	Repeatable application releases and rollback
Infrastructure as Code	Terraform	Hetzner, network, Cloudflare DNS/security and R2 provisioning
CI/CD	Jenkins	Build, test, scan, package, deploy, promote and rollback
Source control	GitHub	Branches, pull requests and immutable commit history
Unit/integration tests	xUnit	Backend regression and business invariants
Frontend tests	Vitest	Frontend regression tests
Browser E2E target	Playwright	Automated customer/seller/admin golden flows
Security scanning	NuGet audit, npm audit, Trivy	Dependency and container release gates
Performance target	k6	Automated lightweight staging smoke/load gate
Documentation	MkDocs Material	Vayzo DevOps/engineering knowledge base

Target-state labels: Playwright-based full browser golden-flow coverage and k6 release gates are part of the automation-hardening plan. They should be treated as required CI/CD capabilities before the production pipeline is declared fully automated.

3. Marketplace feature catalogue¶

Customer experience¶

Registration, login, secure browser session and logout.
Category and product discovery.
Product variants, seller offers, availability and pricing.
Search, filtering and sorting.
Product details, images, rating summaries and verified-purchase reviews.
Cart and multi-seller checkout.
Server-authoritative checkout pricing.
Coupons/promotions with platform-funded and seller-funded accounting.
Razorpay order/payment verification flow.
Customer addresses/profile flows.
Parent order plus per-seller fulfilment visibility.
Shipment tracking.
Return requests and reverse-logistics tracking.
Partial/multiple-partial refund accounting.
Review creation/editing after verified purchase.
In-app notifications.

Seller experience¶

Seller marketplace onboarding/administrative approval support.
Seller listings over the shared marketplace catalogue.
Product variant selection and seller SKU/price management.
Warehouse inventory management.
Reserved stock protected from direct seller edits.
Seller order fulfilment state machine: Processing -> Confirmed -> Packed -> ReadyToShip -> Shipped -> Delivered.
Safe pre-shipment cancellation and stock restoration.
Shipment/logistics management.
Returns approval/rejection and reverse-logistics workflow.
Inspection/QC with restock versus damaged quantities.
Coupon management/funding visibility.
Settlement list/detail/summary.
Reviews visibility.
Seller dashboards and reporting.
In-app notifications.

Administrator experience¶

User/seller administration and seller KYC/approval support.
Marketplace product/category/variant administration.
Seller-order and fulfilment visibility.
Payment reconciliation visibility.
Settlement generation and lifecycle management.
Logistics visibility.
Returns/refunds ledger and operational visibility.
Review moderation.
Promotion/coupon administration.
Marketplace dashboards and reports.
In-app notifications.

Marketplace and financial integrity¶

Multi-seller parent order split into seller sub-orders.
Inventory reservation before payment confirmation.
Atomic reservation commit/release and expiry handling.
Multi-replica-safe reservation expiry processing.
Payment amount calculated by the server, never trusted from the browser.
Durable payment reconciliation records.
Immutable settlement financial snapshots.
Commission calculation on the defined commission base.
Pre-settlement and post-settlement refund handling.
Immutable post-settlement adjustment records.
Coupon discount allocation and funding snapshots.
Race-safe coupon usage and return quantity accounting.
Server-authoritative reporting over persisted financial snapshots.

Launch notification policy¶

In-app: enabled.
Email: disabled until a real provider is implemented and production-approved.
SMS: disabled until a real provider is implemented and production-approved.
WhatsApp: not implemented for initial release.
Push: not implemented for initial release.

4. Kubernetes runtime model¶

Namespaces¶

akshayabazaar-staging
akshayabazaar-production

Each environment has its own Helm release and Kubernetes Secret set.

Core workloads¶

frontend Deployment
frontend Service
backend Deployment
backend Service
migration Job
Ingress
ConfigMap
Secret
HPA
NetworkPolicy
ServiceAccount

Health model¶

/health/live confirms the process is running.
/health/ready gates traffic on critical dependencies including MySQL and Redis.
Kubernetes startup/liveness/readiness probes should use these application endpoints.

Scaling model¶

The production backend is designed for horizontal scaling. Current release policy targets a backend HPA of 2-6 replicas. Multi-replica-sensitive inventory expiry processing must remain protected by the existing concurrency-safe implementation.

Migration model¶

Database migrations are not run manually and are not mixed into normal API startup. The release pipeline runs the application's --migrate-only path through the Helm/Kubernetes migration Job before the serving workload is promoted.

5. Fully automated CI/CD architecture¶

Developer / AI coding agent
          |
          v
      GitHub branch
          |
          v
      Pull Request
          |
          v
+----------------------------------+
| Jenkins CI quality gates         |
|                                  |
| backend restore/build/test       |
| frontend install/test/lint/build |
| NuGet + npm dependency audit     |
| Terraform validate               |
| Helm lint/render                 |
| Docker build                     |
| Trivy image scan                 |
+----------------+-----------------+
                 | PASS
                 v
             Merge / Tag
                 |
                 v
+----------------------------------+
| Jenkins release pipeline         |
|                                  |
| build immutable SHA images       |
| push images to GHCR              |
| Terraform plan/apply             |
| backup preflight                 |
| Kubernetes migration Job         |
| Helm upgrade --atomic --wait     |
+----------------+-----------------+
                 |
                 v
             STAGING
                 |
                 v
+----------------------------------+
| Automated release verification   |
|                                  |
| rollout + health checks          |
| API/integration tests            |
| customer browser E2E             |
| seller browser E2E               |
| admin browser E2E                |
| Razorpay test-mode verification  |
| R2 upload/read verification      |
| inventory/concurrency checks     |
| security smoke tests             |
| lightweight performance gate     |
+----------------+-----------------+
                 | PASS
                 v
          Release candidate
                 |
                 v
       ONE PRODUCTION APPROVAL
                 |
                 v
+----------------------------------+
| Production promotion             |
|                                  |
| promote SAME image SHA           |
| backup                           |
| migration Job                    |
| Helm atomic rollout              |
| post-deploy health/smoke tests   |
| release evidence                 |
+----------------+-----------------+
                 |
          +------+------+
          |             |
        PASS           FAIL
          |             |
          v             v
        DONE       Helm/Jenkins
                   rollback

Key release rule: promote, do not rebuild¶

The backend/frontend image SHA that passes staging is the same immutable image SHA promoted to production. Production approval therefore approves a tested artifact rather than authorizing a new build.

6. Pipeline responsibilities¶

Pull-request pipeline¶

Runs automatically for every relevant PR change:

Checkout and metadata.
Backend restore/build.
Backend xUnit tests.
Backend dependency vulnerability audit.
Frontend npm ci.
Frontend/Vitest tests.
ESLint.
Production frontend build.
npm production vulnerability audit.
Terraform format/validate/plan checks as appropriate.
Helm lint/render checks.
Docker build validation.
Trivy filesystem/image scanning.
Secret/config safety checks.

A failed gate stops the pipeline. No deployment occurs from an unqualified PR.

Staging deployment pipeline¶

Staging deployment should be automated end-to-end:

Resolve immutable Git SHA.
Build Docker images once.
Scan images.
Push SHA-tagged images to GHCR.
Run Terraform plan/apply for required infrastructure drift.
Run database backup/preflight where applicable.
Execute Kubernetes migration Job.
Deploy the Helm release with --atomic --wait.
Wait for Kubernetes rollout and readiness.
Execute automated verification suite.
Archive test/security/release evidence.

No SSH, nano, manual kubectl deployment, manual Docker restart or manually executed EF migration belongs in the normal staging path.

Production promotion pipeline¶

Confirm every staging/release gate is green.
Pause at the single named production-approval gate.
Promote the exact staging-tested image SHA.
Verify production infrastructure/config prerequisites.
Create/verify database backup.
Execute migration Job.
helm upgrade --install ... --atomic --wait.
Execute production-safe health/smoke tests.
Archive release evidence.
Mark release complete or roll back automatically on failure.

7. Automated rollback strategy¶

There are two rollback layers.

Helm rollout failure¶

Every release uses Helm --atomic. If new pods fail to become Ready inside the configured timeout, Helm returns the release to the previous revision automatically.

Post-deployment verification failure¶

If Kubernetes rollout succeeds but automated behavioral checks fail, Jenkins should invoke the explicit Helm rollback path and then verify /health/live and /health/ready on the restored revision.

SHA-tagged container images are immutable and retained, so a previous Helm revision always identifies the exact image that was previously deployed.

Database rollback is not equivalent to Helm rollback. Database migrations must be designed for safe forward-compatible application rollouts, with restore/recovery governed by the backup runbook when a destructive recovery is genuinely required.

8. Release evidence¶

Each staging and production release should automatically capture at least:

Git SHA
release/tag
backend image digest
frontend image digest
Helm release revision
Terraform plan/apply result
migration result
backend test result
frontend test/lint/build result
dependency audit result
Trivy scan result
health/readiness result
customer E2E result
seller E2E result
admin E2E result
payment test result
R2 test result
inventory/concurrency result
security smoke result
performance smoke result
backup result
rollout result
post-deployment verification result
rollback result (when invoked)

This evidence replaces repeated manual release checklists and ad-hoc terminal screenshots.

9. Manual actions intentionally retained¶

The goal is high automation, not unsafe automation. These actions remain controlled:

initial production domain registration and provider onboarding/KYC;
creation/rotation of production provider credentials;
first-time privileged secret bootstrap;
one production release approval;
destructive database recovery;
exceptional emergency rollback override;
launch-specific real-money verification when explicitly approved.

Everything else in normal development, staging deployment, verification and production promotion should be pipeline-driven.

10. Development and deployment sequence¶

Feature development
      |
      v
PR + automated CI
      |
      v
Merge to release/master strategy
      |
      v
Immutable Docker images
      |
      v
Terraform infrastructure reconciliation
      |
      v
Kubernetes migration Job
      |
      v
Helm atomic staging deployment
      |
      v
Automated staging E2E/security/performance verification
      |
      v
Release candidate
      |
      v
Single production approval
      |
      v
Promote same images
      |
      v
Backup + migration + Helm atomic production rollout
      |
      v
Automated post-deploy verification
      |
      +---- PASS ---> Release complete
      |
      +---- FAIL ---> Automated rollback / incident path