오랜 기간 백엔드 세계에는 두 가지 거대한 흐름이 있었습니다. 하나는 “요청당 스레드 하나(Thread-per-request)”를 사용하는 자바(Java) 식의 전통적인 방식이고, 다른 하나는 […]

고성능 백엔드 시스템을 지탱하는 핵심은 캐싱(Caching)입니다. 하지만 공교롭게도 가장 인기 있는 데이터의 캐시가 만료되는 순간, 시스템은 가장 취약한 상태가 됩니다.

데이터베이스를 운영하다 보면 귀신이 곡할 노릇을 경험합니다. 인덱스도 적절히 걸려 있고 쿼리도 튜닝되어 있는데, 시간이 지날수록 검색 속도가 조금씩 느려지는

데이터베이스의 ACID 원칙 중 ‘I’는 고립성(Isolation)을 의미합니다. 여러 트랜잭션이 동시에 실행될 때 서로 얼마나 고립되어야 하는지를 정의하는 것이 바로 격리

DB 샤딩(Sharding)과 일관된 해싱(Consistent Hashing): 데이터가 늘어나도 부하를 균등하게 분산하는 공식 서비스가 대박이 나서 사용자 수가 수백만 명을 넘어서면, 제아무리

데이터베이스를 선택할 때 우리는 흔히 “MySQL은 안정적이고, Cassandra나 RocksDB는 쓰기가 빠르다”라고 말합니다. 하지만 왜 그런 차이가 발생하는지 깊이 고민해 본

네트워크 세상은 늘 불확실합니다. 사용자가 결제 버튼을 눌렀는데 무선 인터넷이 잠시 끊겼다고 가정해 봅시다. 사용자는 결제가 안 된 줄 알고

과거에는 ‘범용 API(General-purpose API)’ 하나를 잘 만들어서 웹에서도 쓰고 앱에서도 쓰는 것이 미덕이었습니다. 하지만 서비스가 성장하고 클라이언트의 요구사항이 파편화되면서 문제가

전통적인 CRUD(Create, Read, Update, Delete) 아키텍처에서는 하나의 데이터 모델을 사용해 데이터를 저장하고 조회합니다. 소규모 시스템에서는 이 방식이 직관적이고 효율적이지만, 사용자가

단일 데이터베이스를 사용하는 모놀리식 아키텍처에서는 @Transactional 어노테이션 하나면 모든 것이 해결되었습니다. 하지만 마이크로서비스 아키텍처(MSA)로 넘어오면 상황이 달라집니다. 주문, 결제, 재고