Scalable Small .NET E‑Commerce Architecture: Monitoring, DB Master‑Slave & Capacity Planning

Small E‑Commerce Architecture Overview

The article begins by describing how a small e‑commerce platform typically starts with a simple LAMP‑style stack (Apache, PHP, MySQL) and then evolves into a .NET‑based architecture that includes MVC, caching, and a relational database.

Technical Architecture

Front‑end sites and mobile M‑sites are deployed in a distributed manner behind proxy servers for load balancing, while other subsystems such as merchant portals and admin back‑ends run on single‑machine or master‑slave configurations. Databases, Redis, file storage, and Solr services all use master‑slave replication.

Logging and Monitoring Solution

Monitoring covers server resources, hardware health, system performance, and page‑level metrics. Logs are captured using log4net and stored in databases or files. The article outlines three log types (error, warning, info) and three logging principles: clear level distinction, centralized error handling, and detailed contextual information.

Monitoring components include:

System resource monitoring (CPU, memory, disk, network) – often implemented with Zabbix.

Server health checks via periodic ping.

Service health checks for web, image, search, and cache services.

Application exception aggregation stored in a database and processed via a scheduled job.

Performance monitoring of API calls, SQL execution, and custom alerts.

Database Master‑Slave Architecture

For small sites, a master‑slave (read‑write separation) setup is sufficient. Writes go to the primary server, reads are distributed across one or more replicas. The article mentions three SQL Server synchronization methods—log shipping, transactional replication, and Always On—providing reference links for each.

In C#, the typical approach is to configure two connection strings (master and slave) and route write queries to the master and read queries to the slave, or to inspect the SQL command type (INSERT/UPDATE/DELETE vs SELECT) at runtime.

Demo code (download link provided) illustrates the basic read/write routing logic.

Shared‑Storage Image Server Architecture

The proposed image service uses a shared network directory on a storage server. Applications write images to the shared folder (e.g., \\192.168.1.200\lib\2016\03\04\10\IMG\file.jpg) and a web site (e.g., http://i1.abc.com/lib/…/file.jpg) serves them. Advantages include reduced I/O on application servers, simple read/write semantics, and easy scaling; disadvantages involve configuration complexity, potential performance loss, and a single point of failure.

Mobile M‑Site Construction

The article compares M‑sites with native apps, highlighting benefits such as lower installation friction, easier tracking, faster iteration, and cross‑platform accessibility. It recommends using 51Degrees for device detection, Bootstrap for rapid UI development, and keeping URLs consistent between PC and mobile sites.

System Capacity Estimation

Capacity planning involves estimating total traffic, average QPS, peak QPS (typically 3‑5× average), and single‑machine limits via stress testing. Key formulas: QPS = Concurrency / AvgResponseTime. The guide walks through a sample calculation where a promotional page expects 30 w PV, leading to an average QPS of 2 500 and a peak QPS of 5 000. It then shows how to determine required server count based on single‑machine QPS limits.

Caching System

Caching (Redis master‑slave) is combined with RabbitMQ and a cache‑cleaner service. When data changes, a message is published to RabbitMQ; the cleaner updates Redis accordingly. The article discusses what data is suitable for caching (high‑cost, low‑frequency updates) and what should not be cached (financial, security‑critical data). Consistency is maintained by updating the cache immediately after database writes.

Overall, the guide emphasizes incremental evolution of architecture, balancing scalability, performance, and reliability while keeping the design simple enough for small to medium e‑commerce teams.