Intro 이 글은 시리즈의 세 번째 글입니다. 앞선 글들에서는 GraphQL, Relay, DDD, CQRS를 함께 가져갈 때 어디서 긴장이 생기는지를 정리했습니다. 통합 그래프를 지향하더라도 경계는 통합하지 않아야 하고, 풍부한 payload를 제공하더라도 command는 말수가 적어야 하며, mutation payload의 최신성은 스키마가 아...
Intro 이 글은 시리즈의 두 번째 글입니다. 앞선 글에서는 GraphQL을 REST의 연장선처럼 쓰게 되는 순간들, 그래프 탐색이라는 감각, 그리고 Relay Cursor Connection이 왜 생각보다 설득력 있게 느껴졌는지를 정리했습니다. 이번 글에서는 그 다음 질문을 조금 더 직접적으로 다뤄보려 합니다. GraphQL, Relay...
Intro 이 글은 시리즈의 첫 번째 글입니다. GraphQL과 DDD를 본격적으로 붙여 보기 전에, 먼저 제가 GraphQL을 바라보는 관점이 어떻게 바뀌었는지부터 정리해 보려 합니다. GraphQL을 도입한 팀을 보다 보면 흥미로운 장면을 자주 마주치게 됩니다. 스키마를 정의하고, Query와 Mutation을 만들고, 클라이언트에서 필요한 필...
Intro 단일 DB에서 복잡한 다단계 비즈니스 흐름을 ACID 트랜잭션으로 구현하다 보면, 외부 API 호출이 없더라도 순수 DB 작업만으로 트랜잭션이 길어지면서 다양한 문제가 발생합니다. 락 경합, 타임아웃, 동시성 이슈 등으로 인해 시스템 안정성이 흔들리고, 결국 확장성에 한계를 느끼게 되는 경우가 많습니다. 이번 글에서는 1987년 Saga...
Intro 개발 환경을 구성할 때 우리는 늘 선택의 기로에 섭니다. Node.js 관리를 위해 fnm이나 Volta를 설치하고, Java 기반 프로젝트를 위해 다시 SDKMAN을 설정하는 과정은 이제 개발자의 통과 의례와도 같습니다. 하지만 도구가 늘어날수록 관리 포인트는 파편화됩니다. 각 도구마다 다른 설정 파일(.nvmrc, .sdkmanrc ...
Intro 현대적인 백엔드 아키텍처를 설계할 때, Primary Key(PK) 선택은 시스템의 확장성과 성능을 결정짓는 가장 기초적이면서도 중요한 의사결정입니다. 과거에는 AUTO_INCREMENT가 표준이었으나, MSA(Microservices Architecture)와 분산 시스템이 주류가 되면서 UUID의 필요성이 대두되었습니다. 특히 최근 ...
Intro 개발하다 보면 멀티테넌시(Multi-tenancy) 구조를 마주하게 됩니다. 초기 스타트업이나 비용 효율이 중요한 단계에서는 하나의 데이터베이스 인스턴스를 여러 고객(Tenant)이 공유하는 Shared Database, Shared Schema 패턴이 가장 합리적인 선택지입니다. 하지만 프로젝트가 DDD를 지향하고 있다면 여기서 딜레마...
Intro MSA(Microservices Architecture) 환경이나 외부 API 연동이 잦은 시스템을 개발하다 보면, CPU나 메모리 리소스는 여유가 있음에도 불구하고 갑자기 외부 요청이 실패하거나 타임아웃이 발생하는 현상을 마주할 때가 있습니다. 로그를 자세히 살펴보면 EADDRNOTAVAIL 같은 에러를 발견하게 되는데, 이는 애플리케이...