Goal

Get a fast overview of full-stack architecture, with a focus on backend systems.

1. A high-level architecture and technology stack map for full-stack projects.
2. A flash-sale e-commerce case study to connect the architecture with key backend technologies.
3. Practical references for project technology selection and architecture design.

Full-Stack Architecture Overview

The main request path can be understood as “frontend + backend”. The frontend handles client-side business logic, client frameworks, and local runtime behavior. The backend handles ingress, application logic, data, asynchronous workflows, and runtime infrastructure.

Cross-cutting capabilities span all layers and support security, stability, and maintainability.

AI Application Backend Supplement

An AI application backend usually adds model calls, context retrieval, tool calls, asynchronous jobs, and governance capabilities on top of a traditional backend path.

Connecting the Stack with a Flash-Sale E-Commerce System

What Is the Business Scenario?

100 phones available for limited-time purchase
A large number of users submit requests at the same time
The system must guarantee performance, data consistency, and security

Why Use This Scenario?

A flash-sale system is a useful backend architecture case because it includes both a complete business flow and system quality requirements. On the business side, it needs login, eligibility checks, stock decrement, order creation, payment, and cancellation. On the system side, it needs concurrency control, oversell prevention, idempotency, traffic spike buffering, compensation, scaling, and troubleshooting.

To use this scenario to connect the backend technology stack, first break down the problems, then map each problem type to the backend capability layer that solves it:

Business problem -> functional requirement -> application layer / domain layer / data layer
System problem -> non-functional requirement -> ingress layer / cache / MQ / observability / deployment runtime

Requirements and Capability Needs in This Scenario

The requirements in this scenario can be divided into two categories: functional requirements complete the business flow, while non-functional requirements keep the system stable and correct under high traffic, failures, and business edge cases.

Functional requirements:

Non-functional requirements can be grouped into four categories: high performance, high availability, high scalability, and data consistency.

When functional and non-functional requirements are connected, they form the main flash-sale system path:

Preparation phase
-> Preload product stock into Redis
-> Generate campaign configuration, purchase limits, and eligibility tokens

Request phase
-> CDN / Nginx / Gateway
-> Rate limiting, risk control, login check
-> Check campaign time, eligibility, one-order-per-user rule
-> Atomically decrement stock with Redis Lua
-> Publish to MQ after success

Async order phase
-> Worker creates order asynchronously
-> Persist order into MySQL
-> Cancel order after payment timeout
-> Compensate stock

Flash-Sale System Evolution Path

Stage One: Monolith

User -> Nginx -> Spring Boot / Gin monolith -> MySQL

Core path code:

func Seckill(ctx context.Context, userID, skuID int64) {
	// Start a transaction so stock decrement and order creation succeed or fail together.
	tx := db.Begin()

	// Lock the stock row to avoid concurrent requests reading the same stock value.
	stock := tx.Query("select stock from sku where id = ? for update", skuID)
	if stock <= 0 {
		tx.Rollback()
		return
	}

	// Deduct stock.
	tx.Exec("update sku set stock = stock - 1 where id = ?", skuID)

	// Create order.
	tx.Exec("insert into orders(user_id, sku_id, status) values (?, ?, 'created')", userID, skuID)
	tx.Commit()
}

Related technology stack:

This stage completes the loop of reading stock, decrementing stock, and creating orders. As concurrency increases, requests hit the database directly, and stock row locks plus order writes become bottlenecks.

Stage Two: Introduce Redis

User
  |
Nginx
  |
App
  |-- Redis: hot products, stock, eligibility, deduplication
  |-- MySQL: orders, users, product persistence

Core path code:

func Seckill(ctx context.Context, userID int64, skuID string) {
	stockKey := "stock:" + skuID
	userKey := fmt.Sprintf("seckill:user:%d:sku:%s", userID, skuID)

	// Redis Lua atomically completes stock decrement and user deduplication.
	result := redis.Eval(decrStockLua, stockKey, userKey)
	if result != "ok" {
		return
	}

	// Create the order synchronously after the stock pre-decrement succeeds.
	db.Exec("insert into orders(user_id, sku_id, status) values (?, ?, 'created')", userID, skuID)
}

Related technology stack:

This stage moves hot stock decrement from the database to Redis, improving stock checks and decrement throughput. Orders are still written synchronously to the database, so database writes still block when request peaks continue to grow.

Stage Three: Introduce a Message Queue

User
  |
Gateway / Nginx
  |
App
  |
Redis Lua stock decrement
  |
MQ
  |
Order Worker
  |
MySQL

Core path code:

func Seckill(ctx context.Context, userID int64, skuID, requestID string) {
	userKey := fmt.Sprintf("seckill:user:%d:sku:%s", userID, skuID)

	// In the request phase, only validate eligibility, deduplicate, and pre-decrement stock.
	result := redis.Eval(decrStockLua, "stock:"+skuID, userKey)
	if result != "ok" {
		return
	}

	// Publish a message after stock decrement succeeds, then return quickly.
	mq.Publish("order.create", OrderCreateMessage{UserID: userID, SkuID: skuID, RequestID: requestID})
}

func ConsumeOrderCreate(msg OrderCreateMessage) {
	// Create the order asynchronously. A unique request_id constraint guarantees idempotency.
	db.Exec(`
		insert into orders(user_id, sku_id, request_id, status)
		values (?, ?, ?, 'created')
		on duplicate key update request_id = request_id
	`, msg.UserID, msg.SkuID, msg.RequestID)
}

Related technology stack:

This stage uses MQ to buffer traffic spikes. The request path returns quickly, and orders are created asynchronously by workers. Message redelivery, worker restarts, and consumption failures will happen, so order creation must be idempotent.

Production systems must also handle the failure point where stock has been decremented but the message publish fails. A common pattern is to write the pending event to a local message table / Outbox first, let a background job publish it to MQ, and use reconciliation scans to catch events that were not published successfully. Consumers should use message_id, request_id, or a unique order constraint to guarantee idempotency and avoid duplicate orders from duplicate messages.

Stage Four: Service Decomposition

User
  |
API Gateway
  |-- User Service -> User DB
  |-- Order Service -> Order DB
  |-- Stock Service -> Redis / Stock DB

Order Service -> MQ -> Order Worker
Order Worker -> Stock Service / Payment Service

Core path code:

func CreateSeckillOrder(ctx context.Context, userID int64, skuID, requestID string) {
	// The order service first calls the stock service to reserve stock.
	reservationID := stockService.Reserve(userID, skuID, requestID)

	// Create a pending order after stock reservation succeeds.
	orderID := orderRepo.CreatePending(userID, skuID, reservationID)

	// Publish an order event to drive payment, notification, and stock confirmation.
	mq.Publish("order.created", OrderCreatedEvent{OrderID: orderID, ReservationID: reservationID})
}

func ReserveStock(userID int64, skuID, requestID string) string {
	// The stock service still uses Redis Lua internally to make decrement and reservation atomic.
	return redis.Eval(reserveStockLua, "stock:"+skuID, "reservation:"+requestID)
}

func OnOrderCreateFailed(reservationID string) {
	// Release reserved stock when order creation fails, preventing stock from being held forever.
	stockService.Release(reservationID)
}

Related technology stack:

This stage splits users, orders, and stock into independent services that can scale separately according to load. Cross-service paths require compensation events; otherwise order success, stock failure, and payment failure can lead to inconsistent states.

After service decomposition, order, stock, and payment usually cannot rely on a single database transaction. The cross-service flow should be managed by a Saga state machine, for example INIT -> STOCK_RESERVED -> ORDER_CREATED -> PAID -> DONE. When any step fails, the flow enters a compensation state to release stock, close the order, or cancel payment. Compensation can also fail, so it needs retries, idempotency, and an operator intervention path.

Stage Five: Highly Available Production Version

User
  |
CDN / WAF / LB
  |
API Gateway cluster
  |
Service replicas
  |-- Redis Cluster
  |-- MQ Cluster
  |-- MySQL primary-replica / sharding
  |-- Object Storage

Observability
  |-- Metrics: Prometheus
  |-- Dashboard: Grafana
  |-- Logs: ELK / Loki
  |-- Tracing: Jaeger / Tempo / SkyWalking

Core path code:

func SeckillHandler(ctx context.Context, req SeckillRequest) {
	// Rate limit at the gateway or service ingress to protect the backend core path.
	if !limiter.Allow(req.UserID, req.IP) {
		return
	}

	// Create a trace for one flash-sale request across gateway, services, MQ, and database.
	trace := tracing.Start("seckill", req.RequestID)

	// Execute the core business path.
	result := seckillService.Submit(ctx, req.UserID, req.SkuID, req.RequestID)

	// Record metrics and logs for capacity analysis, troubleshooting, and alerts.
	metrics.Record("seckill", result)
	logs.Write(req.RequestID, req.UserID, req.SkuID, result)
	trace.End()
}

Related technology stack:

This stage improves availability through replicas, clusters, rate limiting, and observability. As more components are added, troubleshooting depends on a consistent trace ID, metrics, logs, and alerts.

How to Select Technologies and Design Architecture for Real Business

Architecture design should first clarify business requirements, then translate them into technical requirements, and finally choose between self-managed infrastructure and managed cloud services.

Decision sequence:

Business requirements
-> Technical requirements
-> Cloud provider capabilities

Business Requirements: Clarify the Current Business First

Business requirement discovery should focus on factors that affect architecture shape: core path, read/write pattern, consistency, state complexity, external dependencies, permission boundaries, and delivery constraints.

Technical Requirements: Select Backend Capabilities

Technical requirements come from business requirements and non-functional load. First map business requirements to backend capabilities, then use performance, availability, scalability, and quantitative signals to judge whether the architecture needs to evolve.

From Business Requirements to Technical Capabilities

From Non-Functional Requirements to Technical Capabilities

Architecture selection principles:

1. Confirm the current bottleneck first, then choose components.
2. New components must directly solve a clear problem.
3. Component benefits must exceed their development, operations, and troubleshooting costs.
4. Architecture complexity must match the team’s maintenance capability.
5. Do not introduce heavyweight solutions before there is an actual problem.

Common mistakes:

• Introducing Kafka, Kubernetes, and microservices before a high-concurrency problem appears.
• Applying full DDD to a basic CRUD project.
• Self-hosting too much infrastructure when the team lacks operations capacity.
• Replacing architecture design with a list of cloud products.
• Listing technical terms without explaining problems, costs, and suitable conditions.

Quantitative Signals

Architecture selection needs current load data and growth rate. The ranges below are experience-based references; real judgment depends on business type, API complexity, data model, instance size, and team maintenance capability.

Quantitative signals identify the current bottleneck. If the database is slow, check slow queries and indexes first. If spikes are the problem, check rate limiting and traffic buffering. If jobs accumulate, check consumer capacity. If issues are invisible, add logs, metrics, and tracing first.

Cloud Provider Capabilities: Decide Managed or Self-Managed

Cloud provider capabilities are managed implementations of infrastructure capabilities. Selection should start from the needed capability, then decide whether to use a managed service or operate it yourself.

Small teams and early-stage projects usually prefer managed services to reduce installation, upgrade, backup, disaster recovery, and incident recovery costs. For core transaction paths, check SLA, rate limits, backup restore, cross-AZ capability, failover time, and cost model.

Self-managed infrastructure mainly applies to cost control, compliance requirements, multi-cloud deployment, stronger control, or extreme performance requirements. Before choosing self-management, confirm that the team can handle deployment, upgrades, monitoring, backups, scaling, incident recovery, and security hardening.