CAP 이론과 PACELC: 분산 시스템 트레이드오프

강한 일관성 ◀━━━━━━━━━━━━━━━━━━━━━━━━▶ 약한 일관성
Linearizable → Sequential → Causal → Read-your-writes → Eventual
  (느리지만 안전)                                    (빠르지만 불확실)

N = 복제 팩터 (보통 3)
W = 쓰기 시 응답 필요 노드 수
R = 읽기 시 응답 필요 노드 수

W + R > N  →  강한 일관성 보장 (읽기와 쓰기가 반드시 겹침)

-- Cassandra CQL: 쿼리별 일관성 수준 지정
CONSISTENCY QUORUM;
SELECT * FROM orders WHERE order_id = 'ord-001';

CONSISTENCY ONE;
SELECT * FROM product_views WHERE product_id = 'p-100';

// AWS SDK: 강한 일관성 읽기
GetItemRequest request = GetItemRequest.builder()
    .tableName("Orders")
    .key(Map.of("orderId", AttributeValue.builder().s("ord-001").build()))
    .consistentRead(true)   // ← 강한 일관성 (리더 노드에서 읽기)
    .build();
// consistentRead(false) → Eventual Consistency (기본, 2배 빠름, 비용 절반)

// 강한 일관성: 과반수 노드에 쓰기 확인 + 과반수에서 읽기
db.orders.insertOne(
  { orderId: "ord-001", amount: 50000 },
  { writeConcern: { w: "majority", wtimeout: 5000 } }
);

db.orders.find({ orderId: "ord-001" })
  .readConcern("majority");   // 과반수에 커밋된 데이터만 읽기

// 빠른 읽기: 가장 가까운 노드에서 읽기 (Eventual)
db.orders.find({ orderId: "ord-001" })
  .readPref("nearest")
  .readConcern("local");

정상 상태:
  [Node A] ←→ [Node B] ←→ [Node C]
  
파티션 발생 (Node C가 격리):
  [Node A] ←→ [Node B]     [Node C] (격리됨)
  
CP 시스템 (예: ZooKeeper):
  - A, B: 과반수(2/3) 확보 → 정상 서비스
  - C: 과반수 미달 → 읽기/쓰기 거부 (503 응답)
  
AP 시스템 (예: Cassandra ONE):
  - A, B: 정상 서비스
  - C: 자기 로컬 데이터로 서비스 계속 (stale 데이터 가능)
  - 파티션 복구 후: Anti-entropy로 데이터 수렴

최악의 케이스: 동시 쓰기
  
  Client X → [Node A]: balance = 1000 - 500 = 500
  Client Y → [Node C]: balance = 1000 - 700 = 300  (격리된 C가 구 데이터 기반)
  
파티션 복구 후:
  balance = 500? 300? 두 값이 충돌!
  
해결 방법:
  1) Last-Write-Wins (LWW): 타임스탬프가 늦은 값 채택 (데이터 유실 가능)
  2) Vector Clock: 인과관계 추적 → 충돌 감지 → 애플리케이션이 해결
  3) CRDT: 자동으로 수렴하는 자료구조 (카운터, 집합 등)

@Service
public class InventoryService {
    @Transactional(isolation = Isolation.SERIALIZABLE)
    public void reserve(Long productId, int qty) {
        // 비관적 락: 동시 요청이 순차 처리됨
        Product p = productRepository.findByIdForUpdate(productId)
                .orElseThrow(() -> new ProductNotFoundException(productId));
        
        if (p.getStock() < qty) {
            throw new InsufficientStockException(productId, p.getStock(), qty);
        }
        p.reserve(qty);
        
        // 감사 로그 (변경 추적)
        auditLogRepository.save(AuditLog.of("RESERVE", productId, qty));
    }
}

@Service
public class FeedCounterService {
    private final StringRedisTemplate redisTemplate;
    
    // AP 성향: Redis에 즉시 반영 → 비동기로 DB 동기화
    public Long increaseLikeCount(Long postId) {
        String key = "post:like:" + postId;
        Long count = redisTemplate.opsForValue().increment(key);
        
        // 비동기 DB 동기화 (Eventual Consistency)
        eventPublisher.publish(new LikeCountEvent(postId, count));
        return count;
    }
    
    // 읽기: Redis 먼저, 없으면 DB (Read-your-writes 보장)
    public Long getLikeCount(Long postId) {
        String cached = redisTemplate.opsForValue().get("post:like:" + postId);
        if (cached != null) return Long.parseLong(cached);
        
        return postRepository.findLikeCount(postId);
    }
}

@Service
public class OrderService {
    // CP: 주문 생성은 강한 일관성 (DB 트랜잭션)
    @Transactional
    public Order createOrder(OrderRequest request) {
        inventoryService.reserve(request.getProductId(), request.getQty());  // CP
        Order order = orderRepository.save(Order.from(request));
        paymentService.processPayment(order);  // CP
        return order;
    }
    
    // AP: 주문 조회수는 Eventual Consistency
    public void incrementViewCount(Long orderId) {
        redisTemplate.opsForValue().increment("order:view:" + orderId);  // AP
    }
}

Q1. "데이터가 잠깐 틀리면 돈을 잃나?"
    ├─ Yes → CP (강한 일관성 + 분산 락/트랜잭션)
    └─ No
        Q2. "사용자가 자기가 쓴 값을 즉시 못 보면 혼란스러운가?"
            ├─ Yes → Read-your-writes (세션 일관성)
            └─ No → Eventual Consistency (AP, 최고 성능)