High ConcurrencyHigh Concurrency

kết nối đồng thờiconcurrent connections

10,000

kết nối đồng thờiconcurrent connections

lúc cao điểmat peak

5,000 rps

lúc cao điểmat peak

cho API đọcfor read APIs

p99 < 200 ms

cho API đọcfor read APIs

kết nối DB mỗi instanceDB connections per instance

20

kết nối DB mỗi instanceDB connections per instance

Gateway giới hạn số request đang xử lý và từ chối phần dư. Mỗi instance API chạy virtual thread (Java) hoặc goroutine (Go), nhưng mọi tài nguyên khan hiếm đều có giới hạn riêng: pool kết nối DB và một bulkhead cho dịch vụ pricing. Bật “Pricing chậm” hoặc “Đột biến lưu lượng” để xem hệ thống xuống cấp có kiểm soát.The gateway caps in-flight requests and rejects the rest. Each API instance runs on virtual threads (Java) or goroutines (Go), but every scarce resource has its own limit: the DB connection pool and a bulkhead for the pricing service. Turn on “Pricing slows down” or “Traffic spike” to see controlled degradation.

1. 1

   Pool to bao nhiêu là đủ?How big should a pool be?

   Định luật Little: số việc đang xử lý = thông lượng × thời gian. 5.000 rps, mỗi request giữ kết nối DB 8 ms thì cần 40 kết nối cho cả cụm, 10 cho mỗi instance trong 4 instance. Đặt 20 để có dư. Đoán mò bằng số tròn thường sai cả hai chiều.Little's law: work in flight = throughput × time. At 5,000 rps with each request holding a DB connection for 8 ms you need 40 connections cluster-wide, 10 per instance across 4 instances. Set 20 for headroom. Round guesses are usually wrong in both directions.

   Worker Pool
2. 2

   Nhiều kết nối DB hơn không nhanh hơnMore DB connections is not faster

   PostgreSQL chạy mỗi kết nối bằng một process. Vượt quá số lõi CPU và đĩa, các truy vấn tranh nhau CPU, khoá và bộ nhớ nên thông lượng giảm. Giữ pool nhỏ (HikariCP gợi ý khoảng số lõi × 2), để request chờ ở pool với connectionTimeout ngắn, cân nhắc PgBouncer khi có nhiều instance.PostgreSQL runs a process per connection. Beyond the CPU cores and disks, queries fight over CPU, locks and memory, and throughput drops. Keep the pool small (HikariCP suggests roughly cores × 2), let requests wait at the pool with a short connectionTimeout, and consider PgBouncer with many instances.

   Worker PoolSemaphore
3. 3

   Một phụ thuộc chậm chiếm hết tài nguyênOne slow dependency eats every resource

   Nếu mọi lời gọi dùng chung một pool thread, pricing chậm sẽ giữ hết thread và cả /orders cũng chết. Bulkhead: mỗi phụ thuộc có semaphore hoặc pool riêng, chờ permit có hạn, hết permit thì fallback. Thêm circuit breaker để ngừng gọi khi lỗi kéo dài.When every call shares one thread pool, a slow pricing service holds all threads and /orders dies too. Bulkhead: give each dependency its own semaphore or pool, wait for a permit with a bound, fall back when none is free. Add a circuit breaker to stop calling during a sustained failure.

   SemaphoreCircuit Breaker
4. 4

   Không có timeout thì request dồn đốngWithout timeouts requests pile up

   Một chặng không có timeout giữ thread, kết nối và permit vô thời hạn. Đặt timeout ở mọi chặng: connect, read, chờ pool, và một deadline cho cả request. Truyền deadline xuống dưới (context trong Go) để công việc bị huỷ khi client đã bỏ đi.A hop without a timeout holds threads, connections and permits indefinitely. Put a timeout on every hop: connect, read, pool acquire, and a deadline for the whole request. Propagate the deadline (context in Go) so work is cancelled once the client has gone.

   Cancellation / Context
5. 5

   Quá tải: xếp hàng hay từ chối?Overload: queue or reject?

   Hàng chờ không giới hạn chỉ dời lỗi sang sau: request chờ lâu rồi timeout, trong khi server vẫn tốn công xử lý chúng. Giới hạn số request đang xử lý và độ dài hàng chờ; phần dư trả 503 (quá tải chung) hoặc 429 (vượt hạn mức của từng client) kèm Retry-After.An unbounded queue only postpones failure: requests wait, time out, and the server still spends work on them. Cap in-flight requests and queue length; answer the excess with 503 (overall overload) or 429 (a client over its quota) plus Retry-After.

   Rate LimiterSemaphore
6. 6

   Gọi tuần tự các nguồn độc lậpCalling independent sources one after another

   Tồn kho 40 ms rồi giá 35 ms là 75 ms. Gọi song song còn khoảng 40 ms và giữ thread ngắn hơn, nên cùng số thread phục vụ được nhiều request hơn. Mỗi nhánh vẫn phải có timeout và bị huỷ khi nhánh kia lỗi.Stock at 40 ms then price at 35 ms is 75 ms. In parallel it is about 40 ms and each request holds its thread for less time, so the same threads serve more requests. Every branch still needs a timeout and must be cancelled when the other fails.

   Fan-out / Fan-inFuture / Promise

Endpoint báo giá gọi song song DB và pricing, đặt deadline cho cả request và chặn pricing bằng semaphore. Bản Go thêm bước từ chối sớm khi quá tải.The quote endpoint calls the DB and pricing in parallel, sets a deadline for the whole request and guards pricing with a semaphore. The Go version also sheds load early.

// application.yml: spring.threads.virtual.enabled=true1
//                  spring.datasource.hikari.maximum-pool-size=20
@Service
@RequiredArgsConstructor
public class QuoteService {
    private final StockRepository stock;
    private final PricingClient pricing;           // read timeout 300 ms
    private final PriceCache cache;
    private final Semaphore pricingBulkhead = new Semaphore(40);2
    private final ExecutorService vt = Executors.newVirtualThreadPerTaskExecutor();

    public Quote quote(long productId) throws Exception {
        var stockF = CompletableFuture.supplyAsync(() -> stock.available(productId), vt);3
        var priceF = CompletableFuture.supplyAsync(() -> price(productId), vt);
        return stockF.thenCombine(priceF, (s, p) -> new Quote(productId, s, p))
                .orTimeout(500, TimeUnit.MILLISECONDS)4
                .get();                            // TimeoutException → 504
    }

    private Money price(long productId) {
        if (!tryEnter()) {
            return cache.lastKnown(productId);     // bulkhead full: degrade
        }
        try {
            Money m = pricing.get(productId);
            cache.put(productId, m);
            return m;
        } finally {
            pricingBulkhead.release();
        }
    }

    private boolean tryEnter() {
        try {
            return pricingBulkhead.tryAcquire(50, TimeUnit.MILLISECONDS);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return false;
        }
    }
}

type Server struct {
	db       *pgxpool.Pool // pool_max_conns=20
	pricing  *PricingClient
	cache    *PriceCache
	inflight chan struct{} // cap 500 per instance: admission limit
	bulkhead chan struct{} // cap 40: concurrent pricing calls
}

func (s *Server) Quote(w http.ResponseWriter, r *http.Request) {
	select {
	case s.inflight <- struct{}{}:
		defer func() { <-s.inflight }()
	default:1
		w.Header().Set("Retry-After", "2")
		http.Error(w, "overloaded", http.StatusServiceUnavailable)
		return
	}
	ctx, cancel := context.WithTimeout(r.Context(), 500*time.Millisecond)2
	defer cancel()
	id := r.PathValue("id")

	var stock int
	var price Money
	g, gctx := errgroup.WithContext(ctx)3
	g.Go(func() error {
		return s.db.QueryRow(gctx,
			"SELECT available FROM stock WHERE product_id = $1", id).Scan(&stock)
	})
	g.Go(func() (err error) {
		price, err = s.price(gctx, id)
		return err
	})
	if err := g.Wait(); err != nil {
		http.Error(w, "upstream timeout", http.StatusGatewayTimeout)
		return
	}
	writeJSON(w, Quote{ID: id, Stock: stock, Price: price})
}

func (s *Server) price(ctx context.Context, id string) (Money, error) {
	select {4
	case s.bulkhead <- struct{}{}:
		defer func() { <-s.bulkhead }()
	case <-time.After(50 * time.Millisecond):
		return s.cache.LastKnown(id), nil // bulkhead full: degrade
	case <-ctx.Done():
		return Money{}, ctx.Err()
	}
	p, err := s.pricing.Get(ctx, id)
	if err == nil {
		s.cache.Put(id, p)
	}
	return p, err
}

Mỗi pattern mở bài học tương ứng trong menu Pattern.Each one opens its lesson in the Patterns menu.