이번에는 지난번에 사용했던 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..

주문 생성과 결제는 하나의 비즈니스 트랜잭션이지만, 기술적으로는 DB 트랜잭션(주문)과 외부 API 호출(결제)이 분리되기 때문에 정합성 보장이 필요합니다.저는 이 문제를 Outbox Pattern + Kafka를 사용하여 해결했습니다. 주문 생성 시 결제 요청 이벤트를 저장한 후, Kafka를 통해 결제 서비스를 호출하고, 결제 성공 시 주문 상태를 ‘확정’으로 업데이트합니다.결제가 실패하면 일정 시간 동안 Retry 정책(최대 3회, 10분 간격)을 적용하고, 모두 실패한 경우에는 주문 상태를 ‘결제 실패’로 변경하여 고객에게 알림을 보냅니다.이처럼 분산 환경에서는 Saga 패턴이나 보상 트랜잭션을 통해 각 상태를 명시적으로 관리하고, Kafka 기반의 메시지 재처리 및 DLQ를 함께 활용했습니다. ..