고민보단 실천을

모바일 오프라인 동기화 설계: 충돌 해결과 재시도로 사용자 데이터 지키는 방법모바일은 네트워크가 끊기는 순간이 예외가 아니라 기본값에 가깝다. 그래서 오프라인 동기화는 기능이 아니라 제품 신뢰성 문제다.중급 설계에서는 로컬 저장, 큐잉, 재시도, 충돌 해결 전략을 한 묶음으로 다뤄야 한다. 하나만 빠져도 사용자는 데이터를 잃었다고 느낀다.왜 지금 이 주제가 중요한가다중 디바이스와 간헐적 연결은 충돌을 필연적으로 만든다.단순 last-write-wins는 구현은 쉽지만 사용자가 실제로는 데이터를 잃을 수 있다.백그라운드 동기화는 OS 제약과 배터리 정책에 크게 영향을 받는다.핵심 설계 포인트로컬에는 변경 로그(queue)를 저장하고 서버 반영 전까지 상태를 추적한다.각 변경에는 client-generate..

Spring Boot Resilience4j 실전: timeout-retry-circuit breaker를 '같이' 설계하는 법재시도는 쉽게 붙이지만, 타임아웃과 서킷 브레이커를 같이 설계하지 않으면 폭주를 만든다.원칙Timeout을 먼저 정한다(상한).Retry는 멱등 요청에만, 횟수는 적게(지터 포함).Circuit Breaker로 계속 실패하는 다운스트림을 잠시 격리한다.Bulkhead로 장애 전파를 막는다(격리).설정 예시(application.yml)resilience4j: timelimiter: instances: partnerApi: timeoutDuration: 800ms retry: instances: partnerApi: maxA..

Kafka 재시도 토픽/딜레이/ DLQ 설계: 실패를 '멈춤'이 아니라 '흐름'으로 만들기컨슈머가 실패했을 때 같은 메시지에서 계속 실패하면 파티션이 막힌다. 재시도/지연/DLQ를 설계해 실패를 흐름으로 만들어야 한다.기본 패턴main topic: 정상 처리retry topic: 일정 지연 후 재처리DLQ: 최종 실패를 모아 분석/재처리지연을 만드는 방법여러 retry 토픽(retry-5s, retry-1m...)로 단계를 둔다.컨슈머에서 sleep으로 지연하지 않는다(파티션 막힘).DLQ에 남겨야 하는 정보event_id(또는 message key)실패 reason(코드/요약) + stacktrace(또는 축약)원본 payload(또는 참조 위치)와 재처리 횟수최초 발생 시각/마지막 시각재처리(Repl..

Idempotency-Key 설계 실전: 중복 요청을 안전하게 처리하는 API 패턴네트워크 타임아웃/재시도 때문에 같은 요청이 여러 번 들어오는 건 정상이다. 문제는 주문/결제 같은 요청이 한 번만 실행돼야 한다는 점이다.DB 테이블 설계 예시CREATE TABLE idempotency_keys ( id BIGSERIAL PRIMARY KEY, user_id BIGINT NOT NULL, endpoint TEXT NOT NULL, idem_key TEXT NOT NULL, request_hash TEXT NOT NULL, status TEXT NOT NULL, response_code INT, response_body JSONB, created_at TIMESTAMPTZ NOT NULL ..

DB 데드락 실전: 원인(락 순서) 분석과 재시도/쿼리/인덱스로 줄이는 법데드락은 대부분 락 획득 순서가 서로 다르기 때문에 생긴다. 원인 분석과 예방/완화(재시도) 전략을 정리한다.전형적인 예시-- Tx ABEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 1;UPDATE accounts SET balance = balance + 100 WHERE id = 2;COMMIT;-- Tx B (순서 반대)BEGIN;UPDATE accounts SET balance = balance - 50 WHERE id = 2;UPDATE accounts SET balance = balance + 50 WHERE id = 1;COMMIT;데드락을 줄이는 3가지 큰 ..

Webhook 서버 설계: 서명 검증, 재시도, 중복 처리, 순서 보장 체크리스트목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람API 계약이 자주 깨져서(혹은 깨질까봐) 변경을 두려워하는 팀성능/운영 이슈가 나는데 원인이 '네트워크/헤더/캐시/정책' 쪽인지 헷갈리는 상황문서를 '참고'가 아니라 '계약'으로 쓰고 싶은 팀추천 기본값(실무에서 안전한 시작점)정책(기준)을 먼저 정하고, 구현/도구는 그 다음에 선택한다관측(로그/지표)을 먼..

gRPC 실전 가이드: Protobuf, Deadline, Retry, Streaming 설계 포인트목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람API 계약이 자주 깨져서(혹은 깨질까봐) 변경을 두려워하는 팀성능/운영 이슈가 나는데 원인이 '네트워크/헤더/캐시/정책' 쪽인지 헷갈리는 상황문서를 '참고'가 아니라 '계약'으로 쓰고 싶은 팀추천 기본값(실무에서 안전한 시작점)정책(기준)을 먼저 정하고, 구현/도구는 그 다음에 선택한다관..

백그라운드 잡 설계: 재시도/백오프/중복 방지/스케줄링 실전목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.이 글이 필요한 사람배포/운영 중 5xx/타임아웃/리소스 고갈이 간헐적으로 터지는 팀Kubernetes/Nginx/Docker 같은 인프라 설정에서 원인 찾는 시간이 긴 팀장애를 '재현/측정/완화' 순서로 표준화하고 싶은 팀추천 기본값(실무에서 안전한 시작점)시간 예산(타임아웃)과 종료(드레인)를 먼저 정렬한다운영 설정은 '증상 -> 원인 -> 검증..