"매 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).
# 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 bustopics:- 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.
Antigravity Agent
f8b21af4be