[DOCS] 인프라 아키텍처: 금융 기사 수집, 요약, 전달의 총체적인 구조

[WithFortuna]

동작 흐름

[1] Crawler: (정제) 원문 → MongoDB. 
[2] Crawler → Backend: 메타데이터 등록(API) → RDB.status = PENDING.

[3] Backend(배치/스케줄러): PENDING 기사 선택 → 
    Redis Streams x:summary.request 에 {articleId, …} enqueue →
    RDB.status = QUEUED (jobId/priority 등 기록).

[4] AI Worker(consumer group): x:summary.request 소비 시작 →
    Backend에 ‘시작 알림’을 Streams 또는 HTTP로 전달(택1) →
    RDB.status = IN_PROGRESS.

[5] AI Worker: MongoDB에서 원문 조회 → 요약 생성 →
    MongoDB에 요약 upsert(articles.summary 또는 별도 컬렉션).

[6] AI Worker: x:summary.complete 에 {articleId, model, …, resultRef} publish.
    Backend(complete consumer): 메시지 수신 → Mongo 요약 존재 확인 →
    RDB.status = DONE (실패 시 FAILED, 재시도 정책 반영).

[7] 보존기간 경과 원문 삭제: MongoDB TTL 인덱스 또는 Backend 배치 잡로 정기 삭제.

[WithFortuna]

결정해야할 문제 & 결정

1. 크롤링된 기사 원문을 어디에 저장할 것인가?
S3 or mongoDB
=> 일단 기사 원문을 저장할 필요가 없음. 따라서 S3 사용 안함.
크롤러가 한번 정제된 형식으로 데이터를 가져오므로 바로 크롤러 서버가 바로 MongoDB에 삽입한다.

1-2. 기사 원문을 백엔드 서버를 통해 저장할 것인가 or 직접 넣을 것인가
=> 크롤링 서버가 직접 MongoDB에 저장. 백서버는 MongoDB에서 조회/일부 필드 update만 허용.
하나의 DB에 대해서 read/write를 구분할 수 있으므로 여러 서버가 DB에 접근해도 무방해보임

1-3. 어디에 넣고, 누구를 경유하던간에 백엔드 서버에게 메타데이터 제공은 필요
=> 메타 데이터는 rdb에 저장

1-4. 원문 기사는 주기적으로 delete

---

2-1. 기사 원문을 AI 서버에 전달할 것인데 : 이때 형식? AI 서버의 저장소?
결국,
원문의 ID만 + AI 서버가 직접 mongoDB조회
vs
원문 전체를 http등으로 전달

2-2. 수십개의 기사를 한번에 전달 or 큐에 전달
-> RabbitMQ vs Redis
작업큐 등록 주체: 백엔드서버.
흐름; 큐에 등록 -> rds에 기사 메타데이터 수정 -> ai서버 요약 -> 백이 수신받고 메타데이터 수정
조합: (큐에 등록, 큐 기능, 큐에서 가져다 쓰는 worker)
=>
(AMQP, RabbitMQ, python pika)
vs
(Spring Data Redis, Redis Streams, python aioredis)

---

3. AI 서버에서 요약된 기사문을 전달할 것인데 : 어느 저장소로?
=> AI 서버에서 MongoDB에 직접 데이터를 삽입한다

———————————————————————
<구성 요약>

1. 크롤러 서버
2. 백엔드 서버
3. postgreSQL
4. MongoDB
5. Redis
6. AI 서버