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

id, title, category, aliases, status, canonical_id, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	aliases	status	canonical_id	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-server-architecture	Server Architecture	10_Wiki/Topics	서버 아키텍처 Backend Architecture	verified	self	none	A	0.9	applied	architecture backend distributed-systems scalability		2026-05-10	pending	language framework polyglot 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

# 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

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

import CircuitBreaker from "opossum";

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

4. Outbox pattern

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

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

# 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)