면접에 앞서 카프카를 다시 한번 정리하면서 내가 카프카를 요구사항에 알맞게 설계하면서도 낮은 지연속도, 높은 대역폭등 효율적인 설계를 했는지 확인하기 위해 다시 한번 정리해보려고 한다.동기/비동기 차이점왜 비동기 처리가 필요할까? 동기처리에는 대표적인 단점이 2개 존재한다.첫 번째, 느린 응답 시간이다. 동기 방식에서는 유저 정보 저장, 이메일 발송, 환영 쿠폰 지급 등의 작업이 모두 완료되어야 사용자에게 "완료" 응답을 제공할 수 있따. 만약 서버에 어떠한 문제가 발생하여 지연이 발생한다면 사용자는 한참을 기다려야 하고 사용자의 경험에 부정적인 영향을 미칠 수 있다.두 번째, 각각의 서비스 서버에 영향을 미칠 수 있는 강한 결합상태가 된다. 회원 관련 도메인을 담당하는 사용자 서버와 이메일을 발송하는 ..

이번에는 지난번에 사용했던 match 키워드가 있던 자리에 term을 사용해보려고 한다. 이전 블로그에서 사용했던 쿼리를 다시 사용하기 위해 일단 스니펫을 적어두겠다.이전 코드와 다른게 있다면 이번에는 하나가 아닌 두개의 데이터를 타입을 정의하고 넣을것이다. 왜냐하면 term과 terms를 통해 하나 이상의 값이 일치하는 데이터를 조회하는 과정이기 때문이다. boards_id 와 categories 이렇게 두 개를 생성하고자 한다.DELETE /boardsPUT /boards{ "mappings": { "properties": { "boards_id" : { "type": "long" }, "categ..

검색을 할때 사용할 수 있는 속성은 match가 있습니다. match는 must와 함께 사용하고, text타입의 데이터를 조회text는 유연한 검색에 쓰이는데 must는 score에 영향을 주기 때문 must - score에 영향을 주므로 match 사용 - text 타입 조회filter - score에 영향을 주지 않으므로 term 또는 terms 사용 - text를 제외한 타입 조회 그럼 예시를 통해 확인해보자./boards라는 인덱스를 생성하기 전에 이전에 존재하는 boards를 삭제하고 새로 정의그리고 매핑을 정의한다. 매핑에는 title이라는 데이터를 생성하고 type은 text로 설정DELETE /boardsPUT /boards{ "mappings": { "properties..

ElasticSearch에서 데이터를 추가하거나 삭제, 수정하는 과정에서는 다양한 과정이 거쳐진다. 여기서 다룰 것은 기본적인 CRUD 명령어와 내부 옵션에 대한 설명이다. 1. 인덱스 생성 / 삭제 인덱스 생성PUT /productsPUT /boardsPUT /products_reviews→ 새로운 인덱스를 생성 (테이블 생성과 유사).→ settings 와 mappings 지정 가능. 인덱스 삭제DELETE /productsDELETE /boards→ 인덱스를 완전히 삭제 (문서 + 매핑 모두 제거). 2. 매핑(Mapping) 정의 매핑 추가/수정PUT /products/_mappingPOST /products/_mapping→ 기존 인덱스에 필드 타입 정의 (단, 기존 필드 타입 변경은 불가) ..

메시지 순서 보장뿐 아니라 중복 없이 정확히 한 번만 처리되는(Exactly-once) 이벤트 시스템을 구성하기 위해 다음과 같은 설정과 전략을 적용했습니다.먼저 프로듀서 측에서는 acks=all, enable.idempotence=true, transactional.id를 설정해 중복 전송 방지와 트랜잭션 컨텍스트를 유지했습니다.컨슈머 측에서는 enable.auto.commit=false로 수동 커밋을 적용하고, isolation.level=read_committed로 트랜잭션이 커밋된 메시지만 읽도록 설정했습니다.또한 메시지를 읽은 후 DB 작업과 offset 커밋을 동일 트랜잭션 내에서 처리하여, 중간에 실패가 발생해도 중복 소비나 손실이 없도록 구성했습니다.외부 시스템(DB 등)과의 종단 간 정합..

예매 시스템에서 하나의 좌석을 두 명 이상이 동시에 요청하는 경우, 선착순으로 하나의 요청만 성공해야 하는 문제가 있었습니다.초기에 Redisson Lock을 사용해 동시성 제어를 구현했지만, 부하 테스트 결과 lock 경합에 따른 응답 지연이 심해지는 문제가 발생했습니다.이를 해결하기 위해 Redis LuaScript를 사용해 선점 가능한지 검사 → 선점 상태 등록까지의 작업을 원자적으로 수행하도록 했습니다.예: SETNX seat:123 reservedUserId EX 600 같은 방식으로 10분 간 예약된 상태를 유지하며, 실패 시에는 즉시 실패 응답을 주도록 구현했습니다.결과적으로 동시에 요청이 들어와도 한 명만 선점할 수 있도록 정합성을 보장하면서, 성능도 개선되었습니다. 꼬리 질문1.만약 R..