TL;DR최근 MSA와 EDA에 대해 공부하면서 정리한 내용입니다. MSA는 큰 애플리케이션을 작은 서비스들로 나누는 방식이고, EDA는 이벤트를 중심으로 시스템을 설계하는 패턴이라는 것을 배웠습니다. 두 개념이 함께 사용되면 더 유연한 시스템을 만들 수 있다고 합니다.MSA(Microservices Architecture)란?모놀리식에서 마이크로서비스로모놀리식 아키텍처┌─────────────────────────────────┐│ 단일 애플리케이션 │├─────────────────────────────────┤│ - User Management ││ - Order Processing ││ - Payment ..

이번에 처음으로 DDD(Domain-Driven Design) 오프라인 강의를 듣게 되었다. 평소 객체지향 설계에 관심이 많았지만, DDD는 늘 어렵고 추상적으로 느껴졌던 주제였다. '애그리게이트', '바운디드 컨텍스트' 같은 용어들은 들어본 적은 있지만 정확히 무엇을 의미하는지, 왜 필요한지 제대로 이해하지 못했었다. 이번 강의를 통해 DDD가 단순히 기술적인 패턴이 아니라, 복잡한 문제를 해결하기 위한 사고방식이자 철학이라는 것을 깨달았다. 강의 내용을 정리하면서 DDD의 핵심 개념들이 어떻게 연결되는지 이해할 수 있었고, 이를 기록으로 남기고자 한다.DDD의 본질: 소프트웨어는 도메인 문제를 해결하기 위해 존재한다강의는 에릭 에반스의 책 "도메인 주도 설계"의 핵심 메시지로 시작했다."소프트웨어의 ..

TL;DRLoopers 백엔드 부트캠프 10주차를 마치며, TDD 루틴 구축부터 Kafka 이벤트 파이프라인, Redis 랭킹 시스템까지 겪었던 고민들을 정리했습니다. 아직 주니어로서 부족한 점이 많지만, "왜 이런 선택을 했는지"에 대한 나름의 근거를 갖게 된 것이 가장 큰 성장이라고 생각합니다.전체 여정 요약: 흐름이 연결되며 쌓인 경험들10주 동안의 여정을 돌아보면, 각 주차의 학습이 단순히 독립적인 기술 습득이 아니라 하나의 연결된 흐름이었음을 깨닫습니다. 1-3주차: 기초 다지기와 TDD 루틴 확립E2E → 통합 → 단위 테스트 순으로 점진적 리팩토링 진행"테스트를 작성하는 능력"보다 "설계하는 감각"이 더 중요함을 깨달음실무에서는 테스트 책임을 스스로 정해야 한다는 현실적 문제 직면4-5주차:..

서비스를 운영하다 보면 성능 최적화와 트래픽 비용 절감을 위해 캐시(Cache)를 적극적으로 활용하게 됩니다.하지만 단순히 Redis 같은 캐시 서버를 붙인다고 끝나는 게 아니라, 어떤 전략으로 캐시를 운용할지에 따라 성능, 안정성, 일관성에서 큰 차이가 납니다. 오늘은 자주 쓰이는 대표적인 캐시 전략들을 정리해보겠습니다. 1. Cache-Aside (Lazy Loading)가장 많이 사용되는 기본 캐시 전략흐름애플리케이션이 캐시에서 데이터 조회없으면 DB 조회 후 캐시에 저장이후 요청은 캐시에서 처리특징읽기 많은 API에 적합TTL(Time-To-Live)을 설정하여 데이터 유효기간 관리TTL 만료 시 동시에 많은 요청이 몰리면 Cache Stampede(스탬피드 현상) 발생 가능 → 락(Lock) /..

1. 문제 발견이번 주차 과제에서는 여러 사용자가 동시에 같은 자원을 갱신하는 상황에서 발생하는 Race Condition 문제를 직접 경험하였습니다.로컬 환경에서는 쉽게 드러나지 않지만, 동시 요청이 몰리는 운영 환경이나 부하 테스트 상황에서는 생각보다 자주 발생할 수 있습니다. 대표적인 예시는 다음과 같습니다. 동시에 두 명의 사용자가 같은 상품을 주문 → 재고가 음수가 되는 현상 발생여러 사용자가 동일 포인트를 사용 → 포인트가 부족한데도 결제가 완료되는 문제2. Race Condition이란?Race Condition은 여러 스레드(또는 트랜잭션)가 동시에 같은 데이터에 접근하여 갱신할 때, 실행 순서나 타이밍에 따라 결과가 달라지는 상황을 말합니다. 예시 시나리오사용자 A, B가 동시에 재고 ..

이번 주에 새로 배운 것Mock과 Spy가 어떤 상황에서 유용한지 처음으로 감을 잡을 수 있었습니다.Spy는 특히 void 리턴 타입 메서드의 호출 여부를 검증하는 데 유용하다는 것을 알게 되었습니다.테스트 코드를 먼저 작성하면 자연스럽게 설계가 작아지고 명확해진다는 것을 경험했습니다.테스트 코드를 잘 작성하기 위해서는 기능 요구사항에 대한 명확한 설계가 중요하다는 점도 깨달았습니다.이런 고민이 있었습니다처음에는 Mock만으로도 충분할 줄 알았지만, 실제 동작이 섞이니 흐름이 불안정해져서 혼란스러웠습니다.'외부 API처럼 실제 호출이 일어나는 부분을 검증할때는 어떠한 방법을 활용할 수 있을까?' 라는 고민이 있었습니다.기능 리팩토링을 진행하면서 테스트 코드 없이 구조를 바꿨다면 정말 불안했을 것 같았습..