고민보단 실천을

분산 스케줄링 설계: Cron, Quartz, ShedLock 중 어떤 방식이 운영에 유리한가스케줄러는 단순해 보이지만, 인스턴스가 두 대만 넘어가도 '누가 실행할 것인가'가 운영 이슈가 된다.중급 설계에서는 스케줄 실행 정확도보다 중복 실행 방지, 실패 재시도, 관측 가능성을 먼저 다뤄야 한다.왜 지금 이 주제가 중요한가단일 인스턴스 cron은 간단하지만 장애 조치가 취약하다.Quartz는 강력하지만 운영 복잡도와 상태 저장 비용이 따른다.ShedLock은 간단한 분산 락 기반이지만 정밀한 스케줄 엔진을 대체하진 못한다.핵심 설계 포인트단순 반복 작업이면 플랫폼 수준 cron(Kubernetes CronJob 포함)부터 검토한다.정확한 일정, misfire 처리, 달력 기반 스케줄이 필요하면 Quart..

DB 커넥션 풀 튜닝 실전: HikariCP maximumPoolSize를 감으로 정하면 안 되는 이유커넥션 풀은 많을수록 좋지 않다. DB가 동시에 처리할 수 있는 양보다 커넥션이 더 많아지면 대기열만 늘어난다.중급 운영에서는 애플리케이션 스레드 수와 DB 동시 실행 능력, 쿼리 특성을 함께 보고 풀 크기를 정해야 한다.왜 지금 이 주제가 중요한가커넥션 부족은 바로 느껴지지만, 과도한 풀 크기는 조용히 DB를 포화시킨다.풀 대기 시간은 애플리케이션 병목인지 DB 병목인지 구분하는 핵심 지표다.thread pool, HTTP timeout, transaction 길이와 연결하지 않으면 숫자만 바꾸는 튜닝이 된다.핵심 설계 포인트pool size는 DB CPU 코어 수와 평균 쿼리 시간, 동시성 모델을 기..

Cache-Control 고급 활용: stale-while-revalidate, stale-if-error로 체감 성능 높이기응답을 즉시 보여주면서도 완전히 오래된 데이터만 내보내지 않는 절충안이 필요할 때 `stale-while-revalidate`가 빛난다.중급 팀에서는 캐시 시간을 늘리는 것이 아니라, '신선도와 가용성을 분리해서 다루는 방식'으로 Cache-Control을 설계해야 한다.왜 지금 이 주제가 중요한가캐시를 너무 짧게 두면 원본 서버 부하가 커지고, 너무 길게 두면 신선도 문제가 생긴다.`stale-if-error`는 장애 시 사용자 체감 품질을 지키는 강력한 수단이다.브라우저, CDN, 프록시가 각각 캐시 헤더를 다르게 소비하기 때문에 의도를 명확히 해야 한다.핵심 설계 포인트`ma..

API 버저닝 전략 실전: URI vs Header vs Media Type, 언제 갈아타야 하는가API 버저닝은 URL 취향 싸움이 아니라, 호환성 비용을 어떤 계층에서 감당할지 정하는 선택이다.중급 팀에서는 신규 버전을 만드는 기준, 이전 버전 폐기 절차, 고객사 마이그레이션 가시성까지 포함해 설계해야 한다.왜 지금 이 주제가 중요한가버전 전략이 없으면 하위 호환성 부담이 코드 전체로 퍼진다.버전이 많아질수록 운영/문서/모니터링 비용이 함께 증가한다.중요한 것은 어디에 버전을 넣느냐보다 언제 breaking change로 판단하느냐이다.핵심 설계 포인트URI 버저닝은 명시적이고 디버깅이 쉽지만 경로 중복이 커질 수 있다.Header 또는 media type 버저닝은 자원 식별을 유지하지만 클라이언트와..