[Git Ranker #6] GitHub Search API에서 GraphQL로 전환
Search API의 호출 수와 리뷰 데이터 한계를 넘기 위해 Git Ranker가 GraphQL 기반 연도별 병렬 조회 구조로 바뀐 과정과, 현재 구현이 1년 제약·동적 응답·비용 관리를 어떻게 다루는지 정리한다.
Search API의 호출 수와 리뷰 데이터 한계를 넘기 위해 Git Ranker가 GraphQL 기반 연도별 병렬 조회 구조로 바뀐 과정과, 현재 구현이 1년 제약·동적 응답·비용 관리를 어떻게 다루는지 정리한다.
매일 자정 배치를 설계하면서 ‘어제 데이터만 더하는 방식’을 버리고, 현재는 기준선 + 올해 데이터 재조회 + GraphQL 비용 제어로 진화한 Git Ranker의 Spring Batch 구조를 정리한다.
가입 직후에는 COUNT 쿼리로 즉시 순위를 계산하고, 전체 분포는 MySQL Window Function과 Spring Batch Tasklet으로 다시 맞췄다. 서비스 초기의 ‘1등인데도 낮은 티어’ 문제를 하이브리드 티어 규칙으로 정리한 구현 기록
최근 활동 타임라인을 주는 GitHub Events API가 랭킹 서비스에 맞지 않았던 이유와, Search API 기반 count 집계 방식으로 설계를 바꾼 과정
사용자 수가 많지 않은 GitHub 랭킹 서비스에서, 단순 @Scheduled 대신 Spring Batch를 선택한 이유와 현재 배치 구조를 코드 기준으로 정리한다.
미니 PC 홈랩에서 실제 운영 부담을 만들기 위해 GitHub 활동 랭킹 서비스 Git Ranker를 기획했다. 초기 아이디어가 OAuth, Spring Batch, GraphQL, 관측성 설계로 구체화된 이유를 정리한다.
코딩테스트를 위한 Java 기초부터 자료구조까지 정리 (Java 8 기준, Stream/Lambda 미사용)
Spring Boot + MySQL 구조의 성능 병목을 Redis Stream 비동기 처리로 해결하여 1,666 RPS 달성과 66% 성능 향상을 이룬 과정을 다룹니다.
대기 진료 견적서 상세 조회 API에서 569ms 걸리던 3개의 개별 쿼리를 JOIN과 인덱스 최적화를 통해 50ms로 단축시킨 과정을 다룹니다.
모놀리식 아키텍처의 한계를 극복하기 위해 도메인 주도 설계(DDD)와 포트-어댑터 패턴을 적용한 멀티 모듈 아키텍처로 전환한 과정입니다. 장애 격리와 도메인 경계 명확화를 통해 확장성 있는 시스템을 구축했습니다.