2nd/10_Wiki/Topics/Programming & Language/Server Architecture.md

---
id: wiki-2026-0508-server-architecture
title: Server Architecture
category: 10_Wiki/Topics
aliases: [서버 아키텍처, Backend Architecture]
status: verified
canonical_id: self
duplicate_of: none
source_trust_level: A
confidence_score: 0.9
verification_status: applied
tags: [architecture, backend, distributed-systems, scalability]
raw_sources: []
last_reinforced: 2026-05-10
github_commit: pending
tech_stack:
  language: polyglot
  framework: cloud-native
---

# Server Architecture

## 매 한 줄
> **"매 architecture 는 trade-off 의 명시화"**. Monolith → Modular monolith → Service-oriented → Microservices → Cells/Serverless 의 spectrum 에서 팀 규모, 도메인 복잡도, scale 요구에 맞춰 선택. 2026 현재 majority 는 modular monolith + targeted services.

## 매 핵심

### 매 layer
- **Edge**: CDN (Cloudflare, Fastly), DDoS, TLS termination.
- **Gateway**: API gateway, authn, rate limit (Kong, Envoy, AWS API GW).
- **Application**: stateless service tier (horizontal scale).
- **Data**: OLTP DB, cache, search, object store, queue.
- **Async**: message broker (Kafka, NATS, SQS), workers.
- **Observability**: traces (OTel), metrics (Prom), logs.

### 매 archetype
- **Monolith**: 단일 deploy unit — 작은 팀, 빠른 iteration.
- **Modular monolith**: bounded context 명확, 단일 배포 — 2026 default.
- **Microservices**: 팀당 service, 독립 배포 — Conway's law 정렬 시.
- **Cells**: bulkhead 별 독립 stack — high-availability.
- **Serverless**: Lambda/CF Workers — bursty, low-traffic OK.

### 매 응용
1. SaaS multi-tenant.
2. E-commerce platform.
3. Real-time messaging.

## 💻 패턴

### 1. Stateless service + sticky data
```yaml
# k8s deployment
apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 6
  template:
    spec:
      containers:
      - name: api
        image: app:v1.42
        readinessProbe:
          httpGet: { path: /ready, port: 8080 }
        resources:
          requests: { cpu: 250m, memory: 512Mi }
          limits: { cpu: 1, memory: 1Gi }
```

### 2. CQRS read replica fan-out
```typescript
class OrderService {
  constructor(private writeDb: Pool, private readDb: Pool) {}

  async create(o: Order) {
    return this.writeDb.tx(async (tx) => {
      await tx.insert("orders", o);
      await tx.publish("order.created", o);
    });
  }

  async query(userId: string) {
    return this.readDb.query("SELECT * FROM orders_view WHERE user_id=$1", [userId]);
  }
}
```

### 3. Circuit breaker
```typescript
import CircuitBreaker from "opossum";

const breaker = new CircuitBreaker(callPaymentApi, {
  timeout: 3000,
  errorThresholdPercentage: 50,
  resetTimeout: 30_000,
});
breaker.fallback(() => ({ status: "queued" }));
```

### 4. Outbox pattern
```sql
BEGIN;
INSERT INTO orders (...) VALUES (...);
INSERT INTO outbox (topic, payload) VALUES ('order.created', $1);
COMMIT;
-- separate poller publishes outbox → kafka, then deletes
```

### 5. Backpressure with bounded queue
```go
sem := make(chan struct{}, 100) // max 100 in-flight
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    select {
    case sem <- struct{}{}:
        defer func() { <-sem }()
        handle(w, r)
    default:
        http.Error(w, "busy", 503)
    }
})
```

### 6. Cell-based isolation
```
Customer A → Cell-1 (LB, app, DB shard)
Customer B → Cell-2 (LB, app, DB shard)
Customer C → Cell-1
# Cell failure blast radius = 1 cell only
```

### 7. SLO-based deploy gate
```yaml
# Argo Rollouts
strategy:
  canary:
    steps:
    - setWeight: 10
    - analysis:
        templates: [{ templateName: error-rate-slo }]
    - setWeight: 50
    - pause: { duration: 10m }
    - setWeight: 100
```

## 매 결정 기준
| 상황 | Approach |
|---|---|
| 팀 < 20명, 단일 도메인 | Modular monolith |
| 팀 > 50명, 다 도메인 | Microservices (bounded context별) |
| Bursty traffic, 0 → 1000 RPS | Serverless |
| Multi-tenant, blast radius 우려 | Cells |
| Strong consistency 핵심 | Single-writer + read replicas |
| Eventual OK, throughput 핵심 | Event-driven + CQRS |

**기본값**: modular monolith + Postgres + Redis + 1-2 async workers. 명확히 필요할 때 split.

## 🔗 Graph
- 부모: [[Distributed Systems]] · [[Cloud Native]]
- 변형: [[Microservices]] · [[Serverless]] · [[Event-Driven Architecture]]
- Adjacent: [[Kubernetes]] · [[Service Mesh]] · [[Observability]]

## 🤖 LLM 활용
**언제**: 신규 시스템 설계, scale 병목 분석, monolith → service split 시점 판단.
**언제 X**: 작은 internal tool (overengineering 위험), prototype (속도 우선).

## ❌ 안티패턴
- **Distributed monolith**: 서비스 분리 + 동기 호출 chain — latency, 장애 전파.
- **Premature microservices**: 팀 < 10명에 서비스 20개 — ops 폭발.
- **Shared DB across services**: coupling, schema migration 지옥.
- **No observability**: 분산 시 trace 없으면 디버깅 불가.
- **Synchronous everything**: queue/event 활용 안 하면 cascading failure.

## 🧪 검증 / 중복
- Verified (AWS Well-Architected, Google SRE book, Sam Newman "Building Microservices").
- 신뢰도 A.

## 🕓 Changelog
| 날짜 | 변경 |
|---|---|
| 2026-05-08 | Phase 1 |
| 2026-05-10 | Manual cleanup — server architecture archetypes & patterns (2026 cloud-native) |