ETC/System Design9 [Transactional Outbox] CDC 기반의 transaction log tailing 구현 [Transactional Outbox] 개요 에서는 Transactional Outbox pattern에 대한 이론적인 부분을 살펴보았다.이번 포스팅에서는 실제로 CDC를 사용하여 transaction log tailing 방식을 구현하는 예제에 대해 살펴보도록 하겠다. (전체 코드는 여기에서 확인할 수 있다) 개요다음과 같은 아키텍처의 Transactional Outbox pattern을 구현한다. 동일한 transaction 내에서 서비스 데이터 업데이트와 도메인 이벤트 데이터 저장을 한다.CDC를 통해 DB에 도메인 이벤트 데이터가 추가되었음을 감지하고, '데이터 추가됨 이벤트'를 Kafka topic으로 발행한다.2 에서의 '데이터 추가됨 이벤트' message를 가져온 다음, 이를 도메인 이벤.. 2024. 11. 25. [Transactional Outbox] 개요 꼭 MSA가 아니더라도 개발팀의 규모에 따라 API 서버가 도메인/서비스 별로 분리되어 개발되는 경우가 있다.이때 하나의 서비스에서 이벤트 발생 시 다른 서비스에서도 특정 처리가 필요한 상황이 발생하곤 한다. 예를 들어 '게시판 기반 커뮤니티' 앱에서 '회원 서비스'와 '게시판 서비스'가 분리되어 있는 경우,회원 탈퇴 시 해당 회원의 게시물을 삭제/숨김 처리해야하는 경우가 있다.단순한 개발을 위해 직접적으로 '회원 서비스'가 '게시판 서비스'로 직접 호출을 할 수 있다. 이때 만약 어떤 이유로 인해 '회원 서비스'에서 '게시판 서비스'로 호출을 실패하거나 '게시판 서비스' 호출을 성공하였으나 그 이후 작업에서 오류가 발생하는 경우가 발생할 수도 있다.('게시판 서비스'에서만 데이터가 처리되었고 '회원 서.. 2024. 11. 25. 대기열 시스템 커머스 서비스에서는 이벤트로 인해 짧은 시간에 급격하게 올라가는 트래픽에 대응하기 위해서 대기열 시스템을 적극적으로 활용하고 있다. 대기열 시스템의 실제 구현은 서비스의 요구사항, 트래픽 수준 등에 따라 천차만별이다.이번 포스팅에서는 가상의 요구사항을 제시하고 이를 만족하는 대기열 시스템을 구현해보도록 하겠다. (Fastify 기반의 대기열 시스템 API 예제는 여기에서 확인할 수 있다) 요구 사항이벤트 상품 주문 페이지의 트래픽을 조절할 수 있는 대기열 시스템을 구현한다. 이 시스템의 기능적 요구 사항은 아래와 같다.대기열 시스템은 대기와 입장만 관리하고 입장 이후는 관리하지 않는다.대기열 시스템은 이벤트 상품 주문 페이지에 5초 당 10명의 사용자를 입장시킨다.사용자가 대기할 필요가 없는 경우 바로.. 2024. 11. 12. Read Consistency with Database Replicas by Shopify Shopify의 Read Consistency with Database Replicas에 대한 짧은 분석 read-heavy한 애플리케이션이 있을 때, DB의 쓰기(Write) 기능에 성능 저하를 막기 위해 DB replication을 구성하는 경우가 많다. 즉, 서버에서 쓰기 쿼리는 Primary DB에 보내되 읽기 쿼리는 Replica DB에 보내는 식으로 구성하여 쓰기 성능에 영향을 덜 주는 것이다. 위와 같은 환경에서 Shopify의 포스팅에서 얘기하는 문제는 Replica가 2대 이상으로 구성하였을 때 생기는데, 서버가 여러 번의 쿼리를 통해 조회한 데이터를 aggregation 하는 경우이다. 아래와 같이 2대의 Replica DB를 운용하는 경우를 예를 들어보자. - Replica 1 DB는.. 2022. 12. 9. Types of Time-sequential ID generator 일단 시작에 앞서 auto increment ID를 피하는 이유로는 How to Do UUID as Primary Keys the Right Way의 Why You Should Avoid Auto-Incremented Integers를 참고하길 바란다. 그렇지만 DB의 auto increment ID를 사용하는건 이미 널리 쓰이고 있고 그다지 나쁜 선택이 아니다. 하지만 여러 측면을 고려하였을 때, DB의 auto increment ID를 사용하는 것은 아무래도 좋지않다는 판단을 한 경우라면 이제 ID를 어떻게 ID를 만들지가 중요해진다. UUID v4와 같이 random한 ID의 경우 ID 충돌에 있어 큰 문제는 없지만, random한 값이기에 DB의 Primary Key로 사용하기엔 무리가 있을 수 .. 2022. 10. 17. [채팅 시스템] 특정 키워드에 대해 시스템 메세지 보내기 채팅 서비스가 처음에는 단순히 유저 간에 메세지를 주고받기 위함이었어도, 서비스가 고도화 되다보면 꼭 채팅 도메인과는 관련되지 않아도 서비스와 관련하여 유저의 주의를 끌기 위해 몇가지 기능이 추가될 수 있다. 그 중 하나로는 채팅방에 특정 키워드가 발생했을 때 해당 채팅방에 시스템 메세지를 보내는 기능이 있다. 실제 사례를 예로 들자면 당근마켓의 채팅 시스템 메세지 기능이 있을 것이다. 이처럼 채팅 도메인과는 약간 동떨어졌지만 채팅 시스템과 통합되어야하는 기능에 대해 어떤 식으로 시스템을 설계할지에 대해 정리해본다. 먼저 채팅을 위한 웹소켓 서버의 경우 Scaling을 위해 Message Queue나 Redis Pub/Sub 등을 사용하여 다른 웹소켓 서버와 연결된 유저에게 메세지를 보낼 것이다. 위.. 2022. 9. 13. 이전 1 2 다음
