Transactional Outbox Pattern이벤트로 기반으로 분리된 분산환경에서 우리는 특정 DB 상태를 변경하는 트랜잭션과 함께 이벤트를 발행해야할 때가 있습니다. 가령 웹 서비스에 회원 탈퇴 요청이 왔을 때 회원의 탈퇴가 발생했다는 이벤트를 발행시켜 해당 메
애플리케이션 로직을 설계하면 한 번의 요청에 의해 2가지 이상의 기능을 동작해야하는 경우가 생깁니다. 이 다수의 기능을 하나의 메서드에서 코드로 구현하면 기능과 기능이 강결합(Tight Coupling)이 됩니다. 각 로직을 분리해서 관리하기도 어렵고 특정 기능의 문제
C10K 문제는 1만개의 클라이언트 문제라고 하여 1999년 단 케겔(Dan Kegel)이 제시한 이야기입니다. ‘1만 개의 클라이언트를 동시에 처리할 수 있는 네트워크 I/O 모델 설계 방법’을 묻는 말이며 여기에서 ‘동시에’라는 단어의 의미는 통상 1초를 뜻한다고
자바를 처음 이해할 때 다들 꽤나 어려움을 겪었던 내용이 있습니다. 메서드 시그니처에 선언(declaration)하는 throws 와 try-catch 문(statement)의 차이입니다. 우선 둘의 차이를 비교하기전에 기본적인 내용을 짚고 가겠습니다.자바에서는 발생할
소프트웨어 관리를 하다보면 ‘의존성 지옥’ 문제에 빠지게 된다. 의존성이 높은 시스템에서 명세를 엄격하게하면 모든 패키지의 버전을 업그레이드 해야 배포할 수 있는 경우가 생긴다. 반대로 느슨하게 관리를 하면 버전이 엉켜서 호환이 안맞는 경우가 생길 수있다.이번 글에서는
스프링을 사용하여 개발을 하면서 예외를 가장 예민하게 처리하는 기능 중 하나가 @Transactional입니다. @Transactional은 우리가 아는 데이터베이스의 트랜잭션과 같이 ACID의 특징을 가지면서 더 이상 쪼갤 수 없는 최소 단위의 작업입니다. 트랜잭션
본 내용은 Spring I/O 2022에서 톰 홈버그(Tom Hombergs)가 발표한 내용을 정리한 글입니다.글을 읽으시는 분들은 모놀리스(monolith)기반의 프로젝트에서 개발을 한 경험이 있거나 지금도 개발을 하고 있을 겁니다. 서비스의 규모가 커지면서 우리가
WAS와 DB 사이의 연결을 할 때 가장 비용이 많이 드는 작업은 DB와의 Connection입니다. 하지만 요청이 들어올 때마다 DB와의 커넥션을 그때 그때 맺어준다면 이에 대한 부하는 꽤나 복잡해질 수 있습니다. 이를 보완할 수 있는 방법이 Connection Po
코틀린에서는 check와 require라는 함수를 제공한다. 이펙티브 코틀린 - 아이템5. 예외를 활용해 코드에 제한을 걸어라 에서 자세한 내용이 기재되어있다.By using require and check we get three thingsWe are able to
대규모 객체지향 시스템에서 객체를 취약하게 만드는 문제는 구현 상속(implementation inheritance)에서 빈번하게 발생합니다. 하위 클래스가 상위 클래스의 세부 구현 사항에 의존하게 되면 상위 클래스의 내용이 변경될 때마다 하위 코드의 내용이 깨지고 오
클라이언트와 REST 방식으로 통신하는 API 개발을 할 때, 백엔드 개발자는 처음부터 클라이언트의 모든 변수를 예상하기가 어렵습니다. 백엔드 개발자는 보통 다음과 같은 방법으로 클라이언트의 API 기능을 명세합니다.Rest Docs, Swagger 혹은 직접 작성한
Java의 주요한 특징 중 하나는 ‘하위 호환성'입니다. 자바는 이전 버전과의 호환성을 위해 최대한 보수적으로 발전하였으며 그로인해 자바 생태계를 유지를 했지만 언어적 한계를 극복하지 못하고 보완을 해왔습니다. 그 중 대표적인 케이스가 제네릭(Generic)입니다.제네
2010년 트위터, 페이스북, 아마존 등의 글로벌 기업들이 급부상했습니다. 모바일 등의 클라이언트 증가로 사용자와의 인터랙티브가 많아졌습니다. 이렇게 많은 요청과 응답이 왔을 때 기존 RDBMS로는 성능적인 문제를 해결하기 위해 많은 비용을 들여야 했습니다. 또한 실시
ep, 이거 동작원리가 어떻게 되는지 아세요? 궁금해서요.일을 시작한 지 1년을 갓 넘긴 내게 아직도 머릿속에 맴도는 아찔한 질문이다. 우리 회사는 코드 리뷰를 팀에서 한 줄 한 줄 집요하게 하는 스타일인데, 문제를 짚어내는 리뷰가 아닌 원리를 물어보는 질문에 적잖이