기능 개발이 급급한 회사 제외, 서비스를 하는 회사에 들어갔을때의 공부법임.

1. 여러 회사를 다니다 보면, crud 하는 회사는 결국 db 가 주도함

sql base 의 rdb 는 cap 문제를 끼고 사는데, 흔히 '트랜잭션', 'slow query', 'dead lock' 이라는 문제로 서비스가 점점 느려짐

이걸 crud 로만 풀 수 있을까?

ㅇㅇ 풀수는 있음.

대신 풀려다보면 돈이 기하급수적으로 많이 필요함(scale up, 성능을 높힘)

그래서 cqrs 나 graphql, msa, ddd, sse 등 여러 방법을 제시함(scale out, 서비스의 양을 늘림)

여기서는 crud 를 다른 관점으로 보는것에서 시작 ㅇㅇ

2. db 관련 개념을 잘 아는 것이 중요 ㅇㅇ

cqrs 는 eda(event sourcing + event driven arch) 를 구성하다가도,

데이터 분석까지 도달하면 다른 의미의 eda(cdc + exploratory data analysis) 를 만나게 됨.(warehouse -> lake -> mesh)

graphql 은 n+1, api gateway/aggregate 같은 문제를 만나고,

msa 는 factor 12 app 문제들을 만나고,

ddd 는 빈약한 도메인 모델 문제를 만나고,

sse 는 quic, hateoas 와의 여러 관점으로 오해를 낳음.

위 중 적절한 방식을 채택해야함.

3. 백엔드에서는 위처럼 복잡한 문제에 대한 실전성을 다루고, 나중에는 신인성을 유지하는 시스템을 만들줄 알아야 찐 '백엔드 개발자'가 된다 ㅇㅇ

간단한 crud 를 하더라도 db 에 대해서도 잘알아야 하는데,

나같은 경우는 mysql(책 3권), postgres(책 10권), mongo(책 2권) 분량 정도는 읽어보고나서야 확실히 알게됨

이후에는

postgres, mysql(mariadb), oracle 등등은 통계 관점으로 개발하는거고

chroma, dynamodb, cassandradb, documentdb 등등 nosql 은 집계 관점으로 개발하는걸 이해하게 됨 ㅇㅇ

물론 b-tree, mvcc 같은것도 중요한데, 개념에 가까운거고, 이후에는 system 을 CAP -> PACELC -> Eventually Consistency(Event) -> Causal Consistency(Topology) -> ECS ...

나는 이런식으로 공부함 ㅇㅇ