2nd/10_Wiki/Topic_Programming/Architecture/Macro-architecture.md

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

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-macro-architecture	Macro-architecture	10_Wiki/Topics	verified	self	Macro Architecture System-level Architecture	none	A	0.9	applied	architecture system-design macro-vs-micro		2026-05-10	pending	language framework none none

Macro-architecture

매 한 줄

"매 system-wide structural decision 의 layer". Macro-architecture 는 매 component boundaries, deployment topology, integration style, technology selection 등 매 cross-cutting decision. Micro-architecture (single service 내부 design) 와 대비. 2026 의 macro decisions 는 매 monolith vs microservice, sync vs event-driven, multi-region vs single-region, K8s vs serverless, mesh vs mesh-less.

매 핵심

매 Macro vs Micro

• Macro: matter at system level — 매 service boundary, data ownership, integration protocol, deployment unit, observability backbone.
• Micro: matter within a service — 매 module structure, design pattern, framework choice, internal database schema.
• Boundary: macro 는 매 organizational/team alignment 까지 reach (Conway's Law).

매 macro decision dimensions

1. Decomposition: monolith / modular monolith / microservices / functions.
2. Communication: sync REST/gRPC / async events (Kafka, NATS) / hybrid.
3. State: shared DB / DB-per-service / event-sourced / CRDT.
4. Deployment: K8s / VM / serverless / edge.
5. Topology: single region / multi-region active-active / cell-based.
6. Observability: logs/metrics/traces backbone — OTel + central platform.
7. Security: zero-trust mesh / perimeter / identity backbone (SPIFFE, OIDC).
8. Data plane: CDN / mesh / API gateway / event bus.

매 trade-off principle

• Reversibility: macro decisions are 매 expensive to reverse — invest more in initial analysis.
• Coupling: macro choices set the lower bound of coupling between teams.
• Conway's Law: 매 system architecture mirrors 매 communication structure.

매 응용 (typical macro patterns)

1. Modular monolith 의 service-extraction roadmap.
2. Event-driven backbone (Kafka) 의 system-wide adoption.
3. Multi-region active-active for global low-latency.
4. Cell-based architecture for blast-radius isolation.
5. Platform engineering — internal developer platform (IDP) as macro substrate.

💻 패턴

1. Modular monolith (macro starting point)

app/
  modules/
    billing/      # bounded context
      api/        # public interface
      domain/
      infra/
    inventory/
      api/
      domain/
      infra/
    shipping/
  shared-kernel/  # carefully curated
build.gradle      # one binary, internal module boundaries

2. Microservice extraction (incremental)

# Step 1: Strangler Fig — new feature in new service
# Step 2: Move read paths
# Step 3: Move write paths with dual-write/CDC
# Step 4: Decommission old module

# Macro decision: service boundary = bounded context = team boundary

3. Event-driven backbone

# Kafka cluster as system-wide event bus
topics:
  - order.created
  - order.paid
  - shipment.dispatched

# Each service:
#   - publishes its domain events
#   - consumes others' events for projections
# Macro contract: event schema (Avro/Protobuf) + retention policy

4. Cell-based architecture

Cell-A (US-East): full stack — API + DB + cache + workers
Cell-B (US-East): full stack — independent
Cell-C (EU-West): full stack
Router: hash(tenant_id) → cell
# Blast radius = 1 cell. No cross-cell sync data path.

5. Multi-region active-active

Region: us-east-1
  - API + DB primary (writes)
  - Async replication ↔ us-west-2

Region: us-west-2
  - API + DB primary (writes for local users)
  - Async replication ↔ us-east-1

Conflict resolution: CRDT 또는 last-write-wins with vector clock.
DNS: GeoDNS routing.

6. Platform engineering substrate

# Internal Developer Platform (Backstage + ArgoCD + Crossplane)
templates:
  - new-service:        # one command bootstraps
      - K8s namespace
      - CI/CD pipeline
      - observability hooks
      - secrets vault path
      - on-call rotation
# Macro decision: paved road for 200 dev teams

7. Architecture Decision Record (ADR) — macro discipline

# ADR-042: Adopt Kafka as system event backbone

## Context
We have 12 services with point-to-point HTTP. Coupling is rising.

## Decision
Adopt Kafka. All domain events publish to Kafka.
RPC remains for synchronous request/response.

## Consequences
+ Decoupling, replay, audit log.
- New SRE skill, schema registry overhead, eventual consistency.

## Alternatives considered
- NATS JetStream (lighter but less ecosystem)
- AWS EventBridge (vendor lock-in)

매 결정 기준

상황	Macro choice
<5 dev teams, single product	Modular monolith.
10+ teams, independent deploy	Microservices.
Bursty load, long-tail features	Serverless functions.
Globally distributed users	Multi-region active-active.
Regulated isolation (HIPAA, finance)	Cell-based per tenant tier.
High write throughput, audit need	Event-sourced + CQRS.
Heterogeneous edge (IoT)	Edge compute + central plane.

기본값: 매 startup 은 modular monolith. 매 scaling org 는 selective microservice extraction. 매 platform 은 K8s + OTel + Kafka 의 well-trodden macro stack.

🔗 Graph

• 부모: Software Architecture · System Design
• 변형: Enterprise Architecture
• 응용: Cloud_Native · Microservices · Event-Driven Architecture
• Adjacent: Conway's Law · Architecture Decision Record · Platform Engineering

🤖 LLM 활용

언제: system-wide architecture review, decomposition strategy, technology selection at scale, ADR drafting. 언제 X: 매 single-module refactor, framework-internal design, 매 micro-architecture concern.

❌ 안티패턴

• Microservices for 3-team org: 매 distributed monolith 의 worst-of-both — coordination cost > decoupling benefit.
• Macro decision without ADR: 매 reasoning loss, 매 future team 의 reversal 시 context 부재.
• Premature multi-region: 매 business need 없이 매 cost + complexity 의 2-3x.
• Conway's Law ignorance: 매 architecture vs org chart mismatch — 매 friction permanent.
• Tech-driven macro choice: 매 "Kafka is cool" 의 매 problem 정의 없는 도입.
• Frozen macro architecture: 매 5년 unreviewed — 매 evolutionary architecture 의 부재.

🧪 검증 / 중복

• Verified (Fowler "Microservices" articles, Newman Building Microservices 2nd ed., Hohpe Software Architect Elevator).
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — macro vs micro distinction + 2026 macro patterns (cell, multi-region, IDP)