예시 답변 1
약 110초
DB per service 원칙과 쿼리 최적화 경험을 구체 수치로 닫는 결
마이크로서비스에서는 서비스별 독립 DB를 원칙으로 삼는 편입니다. 하나의 DB를 공유하면 스키마 변경 시 다른 서비스에 영향이 생기고, 장애 격리도 어려워진다고 생각합니다.
사이드 프로젝트에서 주문·재고·사용자 세 서비스를 분리할 때, 주문 서비스에는 PostgreSQL, 재고 서비스에는 Redis를 썼습니다. 재고 조회가 초당 수십 회 발생하는 구조라 RDB보다 인메모리 캐시가 적합하다고 판단했습니다. 처음에는 재고 서비스가 PostgreSQL이었는데, 부하 테스트에서 응답 시간이 300ms를 넘는 경우가 생겨서 Redis로 교체했고, 교체 후 평균 응답 시간이 20ms 이하로 떨어졌습니다.
서비스 간 데이터 일관성은 이벤트 기반으로 맞췄습니다. 주문이 확정되면 Kafka 토픽으로 이벤트를 발행하고, 재고 서비스가 구독해서 감산하는 방식입니다. 완전한 동기 일관성보다 최종적 일관성을 택한 건데, 주문-재고 간 수초 내 동기화가 허용되는 서비스 특성을 고려한 결정이었습니다. 이 경험에서 DB 선택과 통신 패턴을 서비스 특성에 맞게 따로 가져가는 게 MSA의 핵심이라고 느꼈습니다.
이 결의 특징
서비스별 독립 DB 원칙을 명확히 하고, 기술 선택(PostgreSQL→Redis)을 응답시간 수치로 정당화했습니다. 아키텍처 철학과 실행이 일관된 모습입니다.
이 결이 통하는 자리
성능 최적화가 곧 사용자 만족도로 직결되는 서비스형 조직에 호평받습니다. 기술 선택의 근거를 정량적으로 제시할 수 있는 팀 문화에 어울립니다.