# monolith_app.rb
# 처음엔 간단했습니다

class Application
  def handle_request(path)
    case path
    when '/users' then UserController.new
    when '/products' then ProductController.new
    when '/orders' then OrderController.new
    end
  end
end

# 3년 후...
# 500개의 컨트롤러
# 100만 줄의 코드
# 200명의 개발자가 같은 저장소에서 작업

# 문제들:
# - 빌드 시간: 30분
# - 테스트 시간: 2시간
# - 배포: 주말에만 (위험해서)
# - 한 줄 고치려면 전체 재배포
# - "결제팀이 배포했더니 검색이 죽었어요"
# - 신입이 실수로 DB 연결 코드 건드려서 서비스 전체 다운

# "모놀리스는 나쁘다더라. MSA로 가자!"

# 서비스 수: 50개
# 개발자 수: 5명
# 사용자 수: 100명 (...)

services/
├── user-service/
├── user-authentication-service/
├── user-profile-service/
├── user-preference-service/
├── product-service/
├── product-search-service/
├── product-recommendation-service/
├── order-service/
├── order-payment-service/
├── order-shipping-service/
├── notification-email-service/
├── notification-sms-service/
├── notification-push-service/
... (37개 더)

# 문제들:
# - 서비스 하나 고치려면 5개 서비스 수정 필요
# - 로그가 50개 서비스에 흩어짐
# - 로컬 개발 환경 구축에 3일 소요
# - "API 호출 체인이 10단계인데 어디서 느린지 모르겠어요"
# - 배포 파이프라인 50개 관리
# - 5명이 50개 서비스 온콜 (주말 없음)

# Netflix Architecture (2008)

┌─────────────────────────────────────┐
│     Monolithic Application          │
│                                      │
│  - DVD Queue Management              │
│  - User Account                      │
│  - Billing                           │
│  - Shipping                          │
│  - Recommendations                   │
│  - Everything...                     │
│                                      │
└─────────────┬───────────────────────┘
              │
    ┌─────────▼─────────┐
    │  Single Database   │
    │  (Oracle)          │
    └────────────────────┘

# 데이터베이스 하나가 죽으면?
# → 전체 서비스 다운
# → DVD 배송도 멈춤
# → 고객 이탈

# Netflix Architecture (2016)

User Request
    ↓
API Gateway (Zuul)
    ↓
┌───────────────────────────────────────────────────┐
│  Microservices (700+)                             │
├───────────────┬───────────────┬───────────────────┤
│ User Service  │ Auth Service  │ Billing Service   │
│ Profile Svc   │ Recommendation│ Playback Service  │
│ Search Svc    │ Encoding Svc  │ Content Metadata  │
│ Device Svc    │ A/B Test Svc  │ Analytics Service │
│ ...           │ ...           │ ...               │
└───────────────┴───────────────┴───────────────────┘
    ↓               ↓               ↓
Multiple Databases (각 서비스마다)

// 마이크로서비스의 핵심 특징

// 1. 단일 책임
// 각 서비스는 하나의 비즈니스 기능만

// user-service (O)
interface UserService {
  createUser(data: UserData): User;
  getUser(id: string): User;
  updateUser(id: string, data: Partial<UserData>): User;
}

// god-service (X)
interface GodService {
  createUser(...): User;
  processPayment(...): Payment;
  sendEmail(...): void;
  generateReport(...): Report;
  // 너무 많은 책임!
}

// 2. 독립적 배포
// 다른 서비스에 영향 없이 배포 가능

// 3. 데이터베이스 분리
// 각 서비스가 자신의 DB 소유

// User Service DB
users_db/
├── users
├── profiles
└── preferences

// Order Service DB  
orders_db/
├── orders
├── order_items
└── shipments

// 절대 직접 다른 서비스의 DB에 접근하지 않음!
// API로만 통신

// 4. 독립적 확장
// 트래픽 높은 서비스만 확장

kubectl scale deployment user-service --replicas=10
kubectl scale deployment billing-service --replicas=2

// 5. 장애 격리
// 한 서비스 장애가 전체에 영향 최소화

// recommendation-service가 다운되어도
// → 사용자는 여전히 로그인 가능
// → 비디오 재생 가능
// → 단지 추천 기능만 안 됨

// 분산 모놀리스의 전형적인 예

// 모놀리스를 그냥 쪼개기만 함

// user-service
class UserService {
  async createUser(data: UserData) {
    // 1. user-profile-service 호출 (동기)
    const profile = await http.post('http://profile-service/profiles', data);
    
    // 2. user-preference-service 호출 (동기)
    const preferences = await http.post('http://preference-service/prefs', data);
    
    // 3. notification-service 호출 (동기)
    await http.post('http://notification-service/welcome-email', { userId: profile.id });
    
    // 4. analytics-service 호출 (동기)
    await http.post('http://analytics-service/track', { event: 'user_created' });
    
    return profile;
  }
}

// 문제:
// - user-service는 4개 서비스에 의존
// - 하나라도 느리면 전체 느림
// - 하나라도 죽으면 회원가입 실패
// - 모놀리스보다 더 나쁨!

// 올바른 MSA: 느슨한 결합

class UserService {
  async createUser(data: UserData) {
    // 1. 사용자만 생성 (동기)
    const user = await db.users.create(data);
    
    // 2. 이벤트 발행 (비동기)
    await eventBus.publish('user.created', { userId: user.id, ...data });
    
    return user;
    // 빠르게 반환!
  }
}

// profile-service (독립적으로 실행)
eventBus.subscribe('user.created', async (event) => {
  await createProfile(event.userId, event.data);
});

// notification-service (독립적으로 실행)
eventBus.subscribe('user.created', async (event) => {
  await sendWelcomeEmail(event.userId);
});

// 장점:
// - user-service는 빠르게 응답
// - 다른 서비스가 죽어도 회원가입은 성공
// - 각 서비스 독립적 배포
// - 나중에 새 구독자 추가 쉬움

// ❌ 나쁜 예: 기술 계층으로 분리

services/
├── frontend-service/        // UI만
├── business-logic-service/  // 모든 비즈니스 로직
└── database-service/        // DB 접근만

// 문제:
// - 작은 기능 하나 추가해도 3개 서비스 모두 수정
// - 팀 간 조율 필수
// - 배포 조율 필수
// - 모놀리스와 다를 바 없음

// ✅ 좋은 예: 비즈니스 도메인으로 분리

services/
├── user-service/       // 사용자 관리 전체
├── order-service/      // 주문 처리 전체
├── product-service/    // 상품 카탈로그 전체
└── payment-service/    // 결제 처리 전체

// 각 서비스는 자신의 UI + 로직 + DB 포함
// 독립적으로 개발, 배포, 확장 가능

// 모놀리스에서는 간단했던 것

class MonolithService {
  async createOrder(userId: string, productId: string) {
    const user = await this.userRepo.findById(userId);
    const product = await this.productRepo.findById(productId);
    
    if (user.balance < product.price) {
      throw new Error('Insufficient balance');
    }
    
    const order = await this.orderRepo.create({ userId, productId });
    await this.userRepo.update(userId, { balance: user.balance - product.price });
    
    return order;
  }
  // 간단, 빠름, ACID 트랜잭션 보장
}

// MSA에서는...

class OrderService {
  async createOrder(userId: string, productId: string) {
    // 1. User Service 호출 (네트워크!)
    const user = await http.get(`http://user-service/users/${userId}`);
    // 만약 네트워크 지연 500ms?
    // 만약 타임아웃?
    // 만약 서비스 다운?
    
    // 2. Product Service 호출 (네트워크!)
    const product = await http.get(`http://product-service/products/${productId}`);
    // 또 네트워크 문제 가능
    
    if (user.balance < product.price) {
      return { error: 'Insufficient balance' };
    }
    
    // 3. Order 생성
    const order = await db.orders.create({ userId, productId });
    
    // 4. User Service에 잔액 차감 요청 (네트워크!)
    await http.post(`http://user-service/users/${userId}/deduct`, {
      amount: product.price
    });
    // 만약 여기서 실패하면?
    // Order는 이미 생성됨!
    // 롤백 어떻게?
    
    return order;
  }
  // 복잡, 느림, 일관성 보장 어려움, 에러 케이스 폭증
}

# 모놀리스에서 디버깅

User: "주문이 실패했어요"

$ grep "order_id=12345" /var/log/app.log

[ERROR] Order creation failed: Insufficient balance
  at OrderService.create (order_service.rb:45)
  at OrderController.create (order_controller.rb:23)
  
# 5분 만에 원인 파악!

# MSA에서 디버깅

User: "주문이 실패했어요"

# 어느 서비스에서 실패했을까?

$ kubectl logs -f order-service-7d4f9c8b-x4k2m
[INFO] Received order request: order_id=12345

$ kubectl logs -f user-service-6c8a7b9d-m3p1k
[INFO] User balance check: user_id=789, balance=100

$ kubectl logs -f product-service-5b7e6a8c-n2q4j
[INFO] Product price: product_id=456, price=150

$ kubectl logs -f payment-service-4a6d5b7c-k1r3m
[ERROR] Payment processing timeout

$ kubectl logs -f notification-service-3e5c4d6b-j0s2n
[WARN] Order notification failed: order not found

# 어? 결제 타임아웃인가? 주문 생성 안 된 건가?
# 로그가 5개 서비스에 흩어짐
# 시간순 정렬도 안 됨
# Correlation ID도 없음
# 3시간 후에야 원인 파악...

// 스타트업 시작 단계

// ❌ 나쁜 선택
// "우리도 넷플릭스처럼 MSA로!"

// 상황:
// - 팀: 3명
// - 사용자: 0명 (아직 출시 전)
// - 도메인: 아직 불명확
// - 기술: MSA 경험 없음

// 결과:
// - 개발 속도 느림
// - 운영 부담 과중
// - 실패 확률 높음

// ✅ 올바른 선택
// "일단 모놀리스로 빠르게 만들자"

class App {
  // 모든 기능이 하나의 앱에
  // - 빠른 개발
  // - 간단한 배포
  // - 쉬운 디버깅
  // - 낮은 운영 비용
}

// MVP 출시 → 고객 피드백 → 빠른 반복
// 도메인이 명확해진 후 필요시 분리

// 성숙한 서비스

// ✅ MSA 고려 신호들

// 1. 팀 규모
// - 개발자 30명 이상
// - 여러 팀으로 나뉨
// - Conway's Law를 활용

// 2. 배포 충돌
// - 팀 A 배포가 팀 B에 영향
// - 배포 대기열 길어짐
// - 한 팀 실수가 전체 영향

// 3. 스케일링 불균형
// - 추천 엔진만 CPU 집약적
// - 검색만 트래픽 10배
// - 전체 스케일링은 낭비

// 4. 기술 다양성 필요
// - ML 모델은 Python
// - 실시간 채팅은 Go
// - 레거시는 Java
// - 모놀리스에선 불가능

// 5. 독립적 배포 필요
// - 하루 수십 번 배포
// - A/B 테스트 많음
// - 빠른 롤백 필요

// 모놀리스 → MSA 전환은 점진적으로!

// Phase 1: 모놀리스 (현재)
┌────────────────────────────┐
│      Monolith App          │
│  - Users                   │
│  - Products                │
│  - Orders                  │
│  - Payments                │
│  - Everything              │
└────────────────────────────┘

// Phase 2: 첫 번째 서비스 분리 (가장 독립적인 것부터)
┌────────────────────────────┐      ┌──────────────┐
│      Monolith App          │◄────►│   Payment    │
│  - Users                   │      │   Service    │
│  - Products                │      └──────────────┘
│  - Orders                  │
│  - (Payments → delegated)  │
└────────────────────────────┘

// Phase 3: 두 번째 서비스 분리
┌────────────────────────────┐      ┌──────────────┐
│      Monolith App          │◄────►│   Payment    │
│  - Users                   │      │   Service    │
│  - Products                │      └──────────────┘
│  - (Orders → delegated)    │             ▲
└────────────────────────────┘             │
               ▲                           │
               └──────┬────────────────────┘
                      │
               ┌──────▼────────┐
               │  Order Service│
               └───────────────┘

// Phase N: 완전 전환
┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
│  User   │  │ Product │  │  Order  │  │ Payment │
│ Service │  │ Service │  │ Service │  │ Service │
└─────────┘  └─────────┘  └─────────┘  └─────────┘

// 장점:
// - 위험 최소화
// - 학습하며 진행
// - 언제든 되돌릴 수 있음
// - 비즈니스 중단 없음

// API Gateway 없이 (클라이언트가 복잡해짐)

// 모바일 앱에서
const user = await fetch('http://user-service:3001/users/123');
const orders = await fetch('http://order-service:3002/orders?userId=123');
const products = await fetch('http://product-service:3003/products');
const recommendations = await fetch('http://recommendation-service:3004/recommend?userId=123');

// 문제:
// - 클라이언트가 모든 서비스 주소 알아야 함
// - 인증을 각 요청마다 처리
// - 네트워크 요청 많음
// - 서비스 변경 시 모든 클라이언트 수정

// API Gateway 사용

// 모바일 앱에서
const data = await fetch('https://api.myapp.com/v1/dashboard', {
  headers: { 'Authorization': 'Bearer token' }
});
// 한 번의 요청으로 필요한 모든 데이터 받음

// API Gateway에서
app.get('/v1/dashboard', async (req, res) => {
  // 1. 인증 (한 곳에서)
  const user = await authenticate(req.headers.authorization);
  
  // 2. 병렬로 여러 서비스 호출
  const [orders, products, recommendations] = await Promise.all([
    fetch(`http://order-service/orders?userId=${user.id}`),
    fetch(`http://product-service/products`),
    fetch(`http://recommendation-service/recommend?userId=${user.id}`)
  ]);
  
  // 3. 데이터 조합 후 반환
  res.json({
    user,
    orders: orders.data,
    products: products.data,
    recommendations: recommendations.data
  });
});

# Service Mesh 없이: 각 서비스에서 처리

# user-service 코드
app.post('/api/users', async (req, res) => {
  // Retry 로직
  let retries = 3;
  while (retries > 0) {
    try {
      await callNotificationService();
      break;
    } catch (error) {
      retries--;
      await sleep(1000);
    }
  }
  
  // Circuit Breaker 로직
  if (errorRate > 0.5) {
    // 빠른 실패
  }
  
  // Timeout 설정
  // Logging
  // Metrics
  // ... 
  // 비즈니스 로직보다 인프라 코드가 더 많음!
});

# order-service 코드에도 똑같은 코드 복붙...
# payment-service 코드에도 똑같은 코드 복붙...
# 모든 서비스에 중복!

# Service Mesh 사용: 인프라가 처리

# user-service 코드 (깔끔!)
app.post('/api/users', async (req, res) => {
  // 비즈니스 로직만!
  const user = await db.users.create(req.body);
  await callNotificationService(user);
  res.json(user);
});

# Istio 설정 (YAML)
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: notification-service
spec:
  http:
  - timeout: 5s
    retries:
      attempts: 3
      perTryTimeout: 2s
    fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
        
# 모든 통신 설정이 인프라 레벨에서!

// 모놀리스에서는 간단했던 것

async function createOrder(userId, productId) {
  const transaction = await db.transaction();
  
  try {
    // 1. 재고 차감
    await transaction('inventory')
      .where('product_id', productId)
      .decrement('quantity', 1);
    
    // 2. 결제
    await transaction('payments').insert({
      user_id: userId,
      amount: product.price
    });
    
    // 3. 주문 생성
    await transaction('orders').insert({
      user_id: userId,
      product_id: productId
    });
    
    await transaction.commit();
    // 모두 성공 or 모두 롤백
  } catch (error) {
    await transaction.rollback();
  }
}

// MSA에서는: 분산 트랜잭션 불가능!

// Saga Pattern: Choreography (이벤트 기반)

// Order Service
async function createOrder(userId, productId) {
  const order = await db.orders.create({
    user_id: userId,
    product_id: productId,
    status: 'PENDING'
  });
  
  // 이벤트 발행
  await eventBus.publish('OrderCreated', {
    orderId: order.id,
    userId,
    productId
  });
  
  return order;
}

// Inventory Service (구독자)
eventBus.subscribe('OrderCreated', async (event) => {
  try {
    await decrementInventory(event.productId);
    await eventBus.publish('InventoryReserved', event);
  } catch (error) {
    // 보상 트랜잭션
    await eventBus.publish('InventoryReservationFailed', event);
  }
});

// Payment Service (구독자)
eventBus.subscribe('InventoryReserved', async (event) => {
  try {
    await processPayment(event.userId, event.amount);
    await eventBus.publish('PaymentCompleted', event);
  } catch (error) {
    // 보상 트랜잭션
    await eventBus.publish('PaymentFailed', event);
  }
});

// Order Service (구독자 - 완료 처리)
eventBus.subscribe('PaymentCompleted', async (event) => {
  await db.orders.update(event.orderId, { status: 'COMPLETED' });
});

// Order Service (구독자 - 실패 처리)
eventBus.subscribe('PaymentFailed', async (event) => {
  // 보상 트랜잭션: 재고 복구
  await eventBus.publish('CancelInventoryReservation', event);
  await db.orders.update(event.orderId, { status: 'FAILED' });
});

// Inventory Service (구독자 - 보상)
eventBus.subscribe('CancelInventoryReservation', async (event) => {
  await incrementInventory(event.productId);
});

// 복잡하지만 이것이 MSA의 현실!

// "MSA"라고 부르지만 실제로는...

// 1. 분산 모놀리스
// - 서비스 간 강한 결합
// - 동기 호출 체인
// - 공유 데이터베이스
// = MSA가 아님

// 2. 마이크로 모놀리스
// - 서비스는 작은데
// - 모두 함께 배포
// - 버전 의존성 강함
// = MSA가 아님

// 3. 나노서비스
// - 서비스가 너무 작음
// - 함수 하나가 서비스 하나
// - 운영 비용 폭증
// = 과도한 MSA

// 진짜 MSA:
// - 독립적 배포
// - 느슨한 결합
// - 자율적 팀
// - 비즈니스 기능 단위
// - 장애 격리

// 질문에 솔직하게 답해보세요

const questions = [
  "개발자가 50명 이상인가?",
  "하루에 10번 이상 배포하나?",
  "서로 다른 기술 스택이 필요한가?",
  "스케일링이 불균등한가?",
  "팀이 독립적으로 일할 수 있나?",
  "분산 시스템 경험이 풍부한가?",
  "DevOps 문화가 성숙했나?",
  "운영 복잡도를 감당할 수 있나?"
];

let yesCount = 0;
// 5개 이상 Yes? → MSA 고려
// 3개 이하 Yes? → 모놀리스가 나음

// 중요한 것:
// - 비즈니스 가치
// - 팀 역량
// - 유지보수 비용

// 권장 진행 순서

// Phase 1: 모놀리스로 시작
// - 빠른 개발
// - 단순한 아키텍처
// - 도메인 이해하며 학습

// Phase 2: 모듈형 모놀리스
// - 코드를 명확한 모듈로 분리
// - 경계 정의
// - 준비 단계

// Phase 3: 필요할 때 분리
// - 진짜 문제가 생겼을 때
// - 가장 독립적인 부분부터
// - 점진적으로

// Phase 4: 계속 진화
// - 필요한 만큼만
// - 과도하게 분리하지 말 것
// - 언제든 다시 합칠 수 있음

# MSA는 이런 것들을 가능하게 합니다:

✅ 팀 자율성
   → 각 팀이 독립적으로 결정
   
✅ 빠른 배포
   → 다른 팀 기다릴 필요 없음
   
✅ 기술 다양성
   → 문제에 맞는 도구 선택
   
✅ 점진적 확장
   → 필요한 부분만 확장

# 하지만 이런 대가가 있습니다:

❌ 운영 복잡도 증가
❌ 분산 시스템의 어려움
❌ 높은 초기 투자
❌ 전문성 요구

# 트레이드오프를 이해하고 선택해야 합니다