분류 전체보기
-
루프팩 1기 백엔드 10주 완주 후기 - "단순한 코딩을 넘어 진짜 백엔드 개발자로"카테고리 없음 2025. 9. 19. 15:56
수강 전 & 수강 후 변화🔹 수강 전: CRUD만 겨우 만들 줄 아는 주니어 개발자🔹 수강 후: 대용량 트래픽과 장애 상황까지 고려한 지속 가능한 시스템 설계 가능구체적인 변화를 보면:테스트 코드: "귀찮은 것" → "코드의 명세서이자 안전망"으로 인식 전환시스템 설계: 기능 구현에만 급급 → 요구사항 분석부터 다이어그램 설계까지 체계적 접근성능 최적화: "일단 돌아가면 OK" → Index, Cache, 비정규화를 활용한 전략적 성능 개선장애 대응: 문제 발생 시 당황 → Timeout, Retry, Circuit Breaker 패턴으로 선제적 대응 가장 인상 깊었던 학습: 이벤트 기반 아키텍처 (7-8주차)왜 이 부분이 가장 기억에 남는가?'주문' 하나를 처리하는데 포인트, 쿠폰 처리, 재고 관리..
-
Redis ZSet으로 실시간 랭킹 시스템 구축하기Develop 2025. 9. 12. 14:48
TL;DRRedis Sorted Set(ZSET)을 활용하여 대규모 트래픽에서도 빠르게 동작하는 실시간 상품 랭킹 시스템을 구축한 경험을 공유합니다.🚨 문제 인식: 왜 실시간 랭킹 시스템이 필요했나? 우리는 더 좋은 상품을 검색하기 위해 실시간 Ranking 시스템을 구축할 필요성을 느끼고 있었습니다. 🐳 Ranking 시스템의 특성랭킹 정보가 많이 요청됨주기적인 갱신이 필요함조회 빈도가 매우 높아 DB 과부하 ❓ 기존 방식의 문제점초기에는 단순한 DB 쿼리로 해결하려 했습니다:SELECT product_id, view_count, like_count, sale_count, (view_count * 0.3 + like_count * 0.3 + sale_count * ..
-
WIL - Kafka 기반 이벤트 파이프라인Develop/WIL 2025. 9. 7. 13:48
주간 학습 회고 (Weekly I Learned)이번 주는 Kafka 기반 이벤트 처리 시스템 구현에 집중했습니다. 특히 이벤트 기반 아키텍처를 통한 감사, 캐시 무효화, 집계 시스템을 구현했습니다.🧠 이번주 학습 성과 1. Kafka 이벤트 시스템 구축단순한 성능 향상을 넘어선 관심사의 분리장애 격리와 시스템 복원력 향상Consumer Group을 통한 확장 가능한 이벤트 처리이벤트 스키마 설계 시 하위 호환성 고려2. 멱등성의 중요성분산 시스템에서는 중복이 당연히 발생애플리케이션 레벨에서 반드시 처리해야 함3. Partition Key의 중요성파티션키 설계가 메시지 순서 보장의 핵심🤔 아쉬웠던 점과 개선할 부분1. DLQ(Dead Letter Queue) 미구현현재는 실패한 메시지가 무한 재..
-
Kafka 파티션 키 전략Develop 2025. 9. 5. 13:47
개요이커머스 시스템에서 Kafka 파티션 키를 어떻게 설계하고 적용했는지에 대해 다룹니다. 감사 로그, 좋아요 집계, 주문 처리 등 각 도메인별로 어떤 파티션 키 전략을 선택했는지와 그 이유를 설명합니다.파티션 키의 중요성Kafka에서 파티션 키는 다음과 같은 역할을 합니다:순서 보장: 동일한 키를 가진 메시지는 같은 파티션으로 전송되어 순서가 보장됩니다부하 분산: 키의 해시값으로 파티션을 결정하여 부하를 분산시킵니다스케일링: 파티션 수만큼 컨슈머를 병렬로 실행할 수 있습니다도메인별 파티션 키 전략1. 주문 도메인 - OrderEventPublisher@Componentpublic class OrderEventPublisher { public void publishSuccess(Long orderI..
-
WIL - 이벤트 기반 시스템 아키텍처 구축Develop/WIL 2025. 8. 31. 16:55
주간 학습 회고 (Weekly I Learned)이번주는 이커머스 플랫폼의 결합도를 낮추고 확장성을 높이기 위해 이벤트 기반 아키텍처를 전면적으로 도입하는 작업에 집중했습니다. 단순한 동기식 처리에서 벗어나 비이벤트 처리를 통한 시스템 분리와 데이터 플랫폼 연동까지 구현했습니다.🧠 이번주 학습 성과1. 종합적인 이벤트 시스템 설계 및 구현기본 이벤트 인프라 구축 (Event, EventPublisher, EventHandler)이벤트 감사 시스템 구현으로 모든 이벤트 추적 가능주문 이벤트 시스템 구축으로 주문 생명주기 관리결제 이벤트 시스템 구축으로 결제 상태 변화 추적2. 이벤트 기반 좋아요 처리와 집계 분리좋아요 처리와 집계 업데이트를 이벤트로 분리사용자 경험 향상을 위한 즉시 응답 + 백그라운드 ..
-
이벤트 기반 아키텍처 구축기: 주문부터 데이터 플랫폼까지Develop 2025. 8. 29. 14:20
서론기존의 동기식 처리로는 다음과 같은 문제점들이 발생했습니다.🐌 성능 저하: 외부 시스템 호출로 인한 응답 지연🔗 강한 결합: 도메인 간 의존성 증가🚫 장애 전파: 하나의 실패가 전체 플로우에 영향📈 확장성 제한: 새로운 요구사항 추가 시 기존 코드 수정 필요해결책: 이벤트 기반 아키텍처 도입1. 기본 이벤트 시스템 설계EventEnvelope 패턴 (봉투 패턴)모든 이벤트를 감싸는 메타 데이터 컨테이너를 구현했습니다.@Getterpublic class EventEnvelope { private final String eventId; // 이벤트 고유 ID private final LocalDateTime occurredAt; // 발생 시간 private fi..
-
WIL - 장애 허용 시스템 구축Develop/WIL 2025. 8. 22. 21:52
주간 학습 회고 (Weekly I Learned)이번 주의 핵심 미션은 "결제 시스템의 안정성을 극한으로 끌어올리는 것"이었습니다. 외부 PG(Payment Gateway) 연동 시 발생할 수 있는 예측 불가능한 장애에 효과적으로 대응하기 위해, 서킷 브레이커 패턴을 중심으로 재시도(Retry) 로직과 상황별 폴백(Fallback) 전략을 시스템에 체계적으로 적용했습니다.🧠 이번 주 학습 성과1. 재시도와 서킷 브레이커: 2중으로 구성한 안전망단순한 재시도를 넘어, 장애가 지속될 때 시스템 전체를 보호하는 서킷 브레이커를 함께 구현하며 2단계 방어 체계를 구축했습니다.// 1차 방어선: @Retry로 일시적인 오류 극복 시도// 2차 방어선: @CircuitBreaker로 지속적인 장애 전파 차단@Ci..
-
서킷 브레이커 완전 정복 가이드Develop/Infra 2025. 8. 22. 16:05
잠깐, 왜 이게 필요하죠?이커머스에서 결제는 정말 비즈니스의 심장 같은 존재잖아요? 근데 외부 PG(결제 대행사)랑 통신할 땐 별의별 일이 다 생겨요. 갑자기 네트워크가 먹통이 되거나, PG사가 점검 중이거나, 응답이 한참 늦어지거나... 이런 작은 문제 하나가 우리 서비스 전체를 마비시킬 수도 있다니까요!그래서 준비했습니다! 외부 서비스가 말썽을 부려도 우리 시스템은 끄떡없게 만드는 방어막, 서킷 브레이커(Circuit Breaker) 패턴! 실제 결제 시스템에 어떻게 써먹었는지 그 경험과 꿀팁을 싹 다 알려드릴게요. 1. 서킷 브레이커, 그게 뭔데요?이름 한번 직관적이죠? 맞아요, 그 전기 회로 차단기에서 아이디어를 따온 거예요. 특정 서비스에 요청을 보냈는데 자꾸 실패하면 "아, 여긴 지금 맛이 갔..