루퍼스 7주차 WIL Open Weekly Talk 발표 - 글 쓰기 할까말까 고민될 때는 하는 게 역시 좋다는 걸 다시 느낌 발표를 준비하면서 내 글과 다른 분이 쓴 글을 비교해봄. 테크니컬 라이팅에 적절한 구조를 쓰고 있다는 약간(?)의 확신을 느낌 또, 멘토님들의 피드백을 분석하면서 내 글의 강점도 파악할 수 있었음 생각보다 차...

TL;DR Command vs Event: Command는 “너 이거 해”, Event는 “나 이런 일 있었어” 트레이드오프: 결합도와 확장성을 얻는 대신, 추적과 정합성 관리가 어려워진다 주의: AFTER_COMMIT + @Transactional 조합 시 REQUIRES_NEW 필수 들어가며 쿠폰 서비스가 느려지면 주문도 느...

TL;DR SLO을 먼저 고민하자 — “사용자가 서비스를 사용할 때 얼마나 기다릴 수 있을까”를 고민하고, 그 값을 기준으로 Timeout과 CircuitBraker 설정값을 정한다. Slow Call도 에러만큼 위험하다 — 지연은 스레드 고갈로 이어지고, 연쇄 장애를 유발할수 있다. 평소에 TPS/응답 시간을 모니터링하고, API가 느려지...

TL;DR 데이터 특성(변경 빈도, 무효화 복잡도)에 따라 TTL과 무효화 전략을 다르게 가져갔다. 인덱스 방향 최적화 + 캐시 적용으로 p99 1.08s → 74ms(93% 개선), RPS 113 → 153(35% 향상). 들어가면서 이커머스 프로젝트를 하면서 상품 목록 조회, 상품 상세 조회 등 읽기 성능 개선이 필요해졌다. 막...

TL;DR 낙관적/비관적이라는 이름은 충돌에 대한 태도에서 유래했다. 낙관적 락: 충돌이 드물다고 가정하고, 검증 + 롤백 비용을 감수하는 방식. 비관적 락: 충돌이 잦을 것이라 가정하고, 미리 잠그고 줄 세우는 방식. 락 선택 시 충돌 빈도 외에 실패 허용 여부, 트랜잭션 길이, 재시도 비용도 고려해야 한다. 들어가면서 이...

TL;DR 이커머스 시스템에서 “상품 정보 + 부가 정보(브랜드, 좋아요 등)”를 한 번에 내려주는 조합 조회 기능을 설계했다. 처음에는 이 조합을 담당하는 도메인 객체(예: 상품 상세를 표현하는 ProductDetail)를 Domain 레이어에 두고 처리했다. 하지만 하나의 도메인에서 다른 도메인의 상세까지 직접 알아야 해서 경계가 흐...

루퍼스 2주차 WIL 이번 주 핵심 인사이트 설계는 점진적 진화다 - 고도화보다 동작하는 코드 우선 “처음부터 고도화를 생각하지 말고, 조금씩 조각을 한다고 생각하라” 동작하는 코드를 먼저 만들고 점진적으로 개선하는 것이 완벽한 초기 설계보다 실용적 기술적 결정의 “왜”를 설명할 수 있어야 한다 주문-결제 API 분리를 고려한다면?...

TL;DR OrderItem을 처음엔 Value Object로 설계했지만, 도메인을 더 깊게 이해하면서 Entity로 두는 게 더 적절하다고 판단했다. 들어가며 도메인 설계는 언제나 쉽지 않다. 이번에도 이커머스 주문 도메인을 설계하면서 많은 고민이 있었다. 특히 OrderItem을 Value Object로 볼지, Entity로 볼지를 두고 꽤...

📚 루퍼스 1주차 WIL 🎯 이번 주 핵심 인사이트 CS 공부를 깊이있게, 남에게 설명할 정도로 ex) CPU가 100%가 되면 Context Switching 지옥 → 캐시 미스 → Thermal Throttling ex) 메모리가 100%가 되면 Page Cache 제거 → Swap → Thrashing → ...

TL;DR 테스트의 중요성과 1년간 레거시 코드를 테스트 가능한 구조로 개선하며 직접 경험하고 얻은 인사이트를 정리한 글입니다. 들어가며 불과 1년 전만 해도 회사 코드는 서비스 레이어에 비즈니스 로직이 구현되어 있어 테스트 코드를 작성하기가 어려웠다. 테스트 코드가 없으니, 당연히 배포할 때마다 항상 “버그가 나지 않을까?”라는 걱정이 따라왔다....