MSA

카프카를 알아야 하는 이유?카프카 말고도 분산 메세징 시스템은 AWS의 키네시스 등 비숫한 게 많다. 하지만 보편적으로 사용되는 시스템이기에 알아두면 다른 시스템도 이해하기 쉬워진다다음과 같은 효과를 기대할 수 있음대용량 처리고가용성메세지 유실 방지 등 다양한 기능메세지를 받는 서비스가 가용하지 않을 때 카프카가 그 메시지를 가지고 있다가 가용할 때 메세지를 다시 전송하는 매커니즘을 가지고 있음카프카의 구성 요소프로듀서와 컨슈머프로듀서는 메세지를 카프카 시스템에 발행하는 서비스컨슈머는 카프카 시스템에 발행된 메세지를 읽어오는 서비스오프셋은 컨슈머가 어디까지 메세지를 읽었는지를 기록해둔 데이터주문 서비스, 결제 서비스가 있고 주문을 완료하면 결제가 일어나야 한다고 할 때 카프카가 중간에서 메세지를 중계하면..

이번 과제는 Mock을 사용해서 실시간 예약정보를 데이터 플랫폼에 전송한다고 치고, 트랜잭션 내의 로직을 이벤트로 분리하는 것이다또한 MSA 설계로 전환할 때, 어떤 문제가 예상되고 해결할 수 있을지 보고서도 써야함과제일단 이 다음 과제가 kafka 사용이니까, 그걸 고려해서 구현하자현재 구현체에서는 ApplicationEventPublisher 를 사용해서 하면 될 것 같다일단 추상화를 위한 인터페이스부터 만들자interface DomainEventPublisher { fun publish(event: DomainEvent) fun publishAll(events: List)}abstract class DomainEvent ( val eventId: String = UUID.random..

애플리케이션이 커지고 복잡해질수록 '어디까지를 하나의 작업으로 묶어야 하는가'에 대한 고민이 깊어진다. 오늘은 트랜잭션의 범위를 좁히고, 시스템 간의 결합도를 낮추는 이벤트 기반 아키텍처의 핵심 개념을 정리해본다.1. 트랜잭션의 범위는 최소한으로트랜잭션은 데이터의 무결성이 보장되는 선에서 최대한 작게 가져가는 것이 원칙이다. 하나의 트랜잭션이 너무 많은 작업을 물고 있으면 여러 문제가 발생한다.성능 저하와 데드락: 트랜잭션 내에서 너무 많은 행을 수정하거나 느린 조회를 수행하면, DB Lock이 길게 유지된다. 이는 다른 요청의 대기 시간을 늘리고 결국 데드락(Deadlock) 상황을 초래할 수 있다.관심사의 혼재: DB 작업과 상관없는 외부 API 호출이나 알림 발송 로직이 트랜잭션 안에 섞여 있으면,..