[신투 프디아] ERD 트레이딩 시스템 개선기 - 왜 다시 설계했을까?

ERD 트레이딩 시스템 개선기

프로젝트 2주차!

이번 주의 가장 큰 이슈는 세 가지였다.

1. 디자인

2. MSA

3. ERD

 

이번 글에서는 ERD에 있었던 이슈를 정리해보겠다.

 

초기 ERD

 

 

초기 ERD를 바탕으로 trading-service의 Entity를 구현하던 도중 몇몇 문제들을 확인했다.

문제 1. 개인/그룹 계좌와 주식 테이블 간 연결 부재

InvestmentAccount(개인 투자 계좌)와 InvestmentAccountLedger(원장)가 Stock 테이블이 연결되어 있지 않았다.

그룹 투자 구조에서도 동일한 문제가 존재하여, 실제 주식 매매 데이터와 계좌 데이터가 끊겨있었다.

 

그래서! 1차로 수정한 ERD는 다음과 같다.

 

1차 수정 ERD

 

> 계좌–주식 연결 구조 보완을 중점으로, InvestmentAccount와 Stock을 직접 연결하고, 그룹 투자 구조도 동일하게 수정하여 데이터 흐름이 자연스럽게 이어지도록 개선했다.

 

하지만.. 이 ERD에서도 문제는 발생했으니.. 바로

 

문제 2. 매매 관련 테이블 미구성

Order(주문), Trade(체결)와 같은 핵심 매매 테이블이 없었다.

 

계좌 원장(InvestmentAccountLedger)에 입출금과 주식 거래가 뒤섞여 있어 구조가 비효율적이였다.

 

 

문제 3. 집계/조회 데이터와 원본 트랜잭션 데이터의 혼재

Holding, CashBalance, History 등 집계·조회 성격의 테이블이 원본 트랜잭션과 같은 레벨에서 관리되었다.

이로 인해 정합성 관리가 복잡해지고, 대량 집계 시 성능 부담이 예상됐다.

 

 

이 문제들이였다. 가장 중요한 매매 관련 테이블이 없었던 것!!

그리고 캐시 테이블로 빼야하는 것들도 많았다.

 

그래서 다시 고친 최종(을 바라는) ERD!

최종 ERD

 

 

 

>  매매 트랜잭션 테이블 추가

Order(주문), Trade(체결) 테이블을 새롭게 도입하여 실제 증권 매매 프로세스를 반영했다.

계좌 원장에서 거래 기능을 분리하고, 입출금 전용 CashTransaction 테이블을 추가했다.

> 캐시 테이블 분리 및 명시화

Holding(Cache), CashBalance(Cache), History(Cache) 등 집계/조회 목적의 테이블을 캐시테이블로 분리했다.

원본 데이터는 정합성을 보장하고, 캐시는 조회 성능 최적화에 집중할 수 있도록 역할을 분리했다.

 

 

이렇게 큰 문제를 해결한 최종 ERD 완성

 

가장 고민 포인트 중 하나는

캐시 테이블에 FK를 등록하느냐였다.

하지만 정합성을 보장할 필요가 없다고 판단했기에, 컬럼만 등록하는 방향으로 설계했다.

 

ERD만큼 고민했던 디자인과 MSA 글도 빠르게 써야지

 

그럼 ERD 개선기 끝!