SANGWOO.LOG

ssul

8개 · 1/1 페이지

🔀

PayStream Kafka 토픽 & 이벤트 흐름

프로젝트 개요에서 그림 수준으로 정리한 MSA 구조를, Kafka 토픽·이벤트 계약·서비스 간 흐름까지 내려서 문서화한 글입니다. 동기 API(게이트웨이 REST)와 비동기 이벤트(Kafka)의 역할을 구분하고, 알림 서비스가 어떤 이벤트를 구독하는지까지 한곳에 모았습니다. 범위 안내 토픽 이름·페이로드는 팀 합의 기준의 설계안입니다. 일부는 백엔드 구현과 1:1로 맞춰 가는 중이며, 변경 시 이 문서를 함께 갱신합니다. 1. 전체 구조 1-1. 레이어 구분 경로 용도 예시 동기 (REST) 사용자 요청·즉시 응답이 필요한 작업 주문 생성, 결제 요청, 알림 목록 조회 비동기 (Kafka) 다른 서비스 상태 변경 전파, 부하 분리 재고 차감, 결제 완료, 알림 발송 트리거 프론트는 게이트웨이 단일 URL만 호출합니다. ( → notification-service — 연동 기록 참고) 1-2. 게이트웨이 라우팅 (알림 기준) 클라이언트 경로 게이트웨이 백엔드 서비스 인증 예외 n…

2026.06.18
ssul#paystream#kafka#msa#architecture#notification
🔔

PayStream 알림 연동 우선순위 재정리

PayStream 알림 기능을 설계하면서, 처음엔 앱 푸시를 1순위로 두고 진행하려 했다. 그런데 프론트가 네이티브 앱이 아니라 웹뷰·PWA 조합이라는 점이 드러나면서 우선순위를 다시 정리해야 했다. 이번 글은 그 과정에서 확정한 알림 연동 로드맵을 정리한 기록이다. 처음 생각했던 우선순위 앱 푸시 알림 — 특가 알림 등 실시간성이 중요한 알림 이메일 알림 — 공지, 서비스 안내 등 빈도·중요도가 상대적으로 낮은 알림 웹 푸시 알림 — 선택 사항 우선순위를 바꾼 이유 PayStream-web은 네이티브 앱이 아니라 웹뷰 + PWA 구조다. 이 조합에서는 앱 푸시에 필요한 토큰·인증 방식을 바로 적용하기 어렵다. FCM을 쓰려면 네이티브 껍데기까지 고려해야 하고, Web Push를 쓰려면 PWA와 Service Worker 준비가 선행되어야 한다. 결론적으로, 채널 구현보다 먼저 API 연동과 인증 흐름을 검증하는 편이 맞다고 판단했다. 재정리한 연동 순서 1. API 연동 (가장 …

2026.04.23
🧾

API 명세서를 만들어보자!

알림(Notification) 시스템 API 명세서 및 아키텍처 목차 개요 시스템 아키텍처 ERD 구조 API 명세서 이메일 템플릿 API 이메일 발송 API 결론 1. 개요 글 작성에 앞서 알림(Notification) 도메인 중 이메일 알림 시스템을 담당하는 API 명세서와 아키텍처 구조를 정리했습니다. 주요 구성 요소는 (템플릿 관리)와 (발송 이력 관리) 두 개의 테이블로 구성되어 있습니다. 2. 시스템 아키텍처 3. ERD 구조 4. API 명세서 기본 정보 Base URL: https://api.paystream.com/v1 인증 방식: JWT 응답 형식: JSON 공통 규칙 사용 Method: 모든 인증이 필요한 요청은 헤더에 포함 날짜/시간은 ISO 8601 형식() ENUM 필드는 API 문서에서 허용 값과 기본값을 명시 공통 에러 응답 포맷 이메일 템플릿 API 1. 템플릿 목록 조회 설명: 등록된 이메일 템플릿 목록을 페이지네이션과 함께 조회합니다. 템…

2025.09.26
📢

PayStream Project

2주차 프로젝트를 준비하며, 변하지 않은 것 바로 “대용량 트래픽” 1주차 논의결과 간단요약 아키텍처: MSA 배포 구조: Kubernetes 기반 컨테이너 배포 (👀미정이였던 것 같은데) 메시징 시스템: Apache Kafka 인프라: AWS (EKS, RDS 등) 기술 스택: Spring Boot, Spring Cloud, React, MySQL, Redis ㄴ*FE스택과 SQL, 배포구조, Redis는 아직 정리되지 않은 추상적인 부분 오늘 다뤄 볼 내용은 어떤 서비스에 어떤 기술 스택을 사용하고, 왜 사용하는가? 난 뭘 잘할 수 있지? 1. 어떤 서비스에 어떤 기술 스택을 사용하고, 왜 사용하는가? 1-1. 프로젝트 내 서비스 기술 스택 1-2. 추가될만한 서비스 기술 및 스택 요약 2. JAVA 버전과 레포방식 2-1. JAVA 버전 비교 오류를 해결하며, 헤쳐나가는 것이 개발자의 숙명이지만, 사실 초기단계에서 안정성을 배제하고 모험을 하는 것이 맞을까? 하는 생각이기 떄…

2025.09.12
🏗️

PayStream 프로젝트 개요

PayStream은 대용량 트래픽을 전제로 한 MSA 기반 커머스·예약 서비스 사이드 프로젝트입니다. 숙소·특가 도메인을 중심으로 주문, 결제, 재고, 알림, 어드민 대시보드까지 이벤트 기반으로 연결하는 것이 목표입니다. 이 글은 PayStream 시리즈의 허브(목차) 역할을 합니다. 설계 결정, API 명세, 연동 기록은 아래 폴더별 글에서 이어집니다. 프로젝트 목표 항목 내용 핵심 주제 대용량 트래픽 · MSA · 이벤트 드리븐 아키텍처 도메인 숙소·특가 예약/결제 (PayStream-web UI 기준) 백엔드 Spring Boot · Spring Cloud · Kafka · MySQL · Redis 프론트 Next.js 15 (PayStream-web, 웹뷰·PWA 조합) 인프라 AWS (EKS, RDS 등), Kubernetes 기반 배포 검토 한 줄로 말하면, 실서비스에 가까운 규모감을 목표로 기술 스택과 역할 분담을 먼저 정리하고, 알림·API 연동부터 점진적으로 붙여 …

2025.09.10
🥕

당근마켓 크롤러 개발기: 셀레니움부터 aiohttp까지

프로젝트 개요 이번 프로젝트는 당근마켓에서 특정 키워드와 관련된 게시글을 체계적으로 수집하는 크롤러를 개발하는 것이었습니다. 단순한 데이터 수집을 넘어서, 안정성과 효율성을 모두 갖춘 프로덕션 레벨의 크롤러를 만드는 것이 목표였습니다. 프로젝트 규모 항목 수치 비고 크롤링 대상 지역 12,000개 전국 시/군/구 단위 병렬 워커 수 3-10개 서버 성능에 따라 조정 기본 딜레이 2.5초 봇 탐지 회피 예상 소요 시간 4시간 10워커 기준 개발 과정 타임라인 1. 기본 구조 설계 BaseCrawler 추상 클래스와 Selenium, aiohttp 크롤러 구현체 설계 2. 핵심 기능 구현 크롤러 방식 선택, 데이터 수집, 데이터베이스 저장, JSON 내보내기 기능 구현 3. 진행상황 관리 진행상황 저장/복구, 중단/재시작 기능 구현 4. 트러블슈팅 중단 기능, 진행상황 표기, 딜레이 적용 문제 해결, 403 error 대책 5. 최적화 및 완성 성능 최적화, 사용자 경험 개선, 최종 …

2025.08.19
🎄

크리스마스 기념 Bot 만들기(aka.호진이)

AI 사내 봇 제작기 1일차. 업무에 AI 기능을 도입하기 이전부터 학습하는 봇에 대한 궁금점과 효율에 관심이 많았다. 그거슨 자동화는 최적화의 다른 말이니까… 사내 봇 제작에 앞서 간단한 요구사항 명세서를 작성 해 보겠다. 극ENTP 인 성향 상 계획을 좋아하진 않지만, 경험에 의해서 이런 걸 계획없이 진행하면 꼭 산으로 … 가더라ㄱ… 조금 걱정되는게 데이터 스토리지 용량이다. 스토리지 및 용량 대안으로는 FAISS (Facebook AI Similarity Search) 를 생각했다. 사내 봇의 경우 내부 데이터를 다루기 때문에 SEO는 상관이 없고, 단순히 페이지 하나에서 질의응답만 받기 때문에 “SPA에 특화되어있고”, SSR보단 “단순 클라이언트 랜더링”이 요구되고, “타임라인을 2주” 로 잡았기 때문에 빠른개발을 위해서 React를 가용하기로 했다.

2024.12.27

최적화... TDD... 효율... 다 따져

코드 리펙토링을 통한 최적화. 처음 경험했던 최적화? 는 아마 javascript의 메서드 였던 것 같다. 우리 메서드 씨는요… 순회 가능한 객체에 주어진 모든 프로미스가 이행된 후, 혹은 예외처리된 프로미스를 반환해요.. 게임으로 따지면 1보스에서 죽으면 2보스는 트라이도 못하는거다. 응 1단계 못 깼잖아 돌아가~😂 프로젝트를 진행할 때 한개의 서비스에 여러가지의 기능들이 추가되다 보니, API 요청을 처리하는 함수가 여러 개 있었는데, 매번 함수를 호출할 때마다 처리 속도가 느려지는 게 신경 쓰였다. 게다가 수정할 때마다 반복적인 작업이 필요해서 너무 번거롭고 비효율적이라는 걸 자각 해버렸달까… 이걸 계기로 유지보수 편의성과 효율적인 설계가 얼마나 중요한지 확실히 깨닫게 됐다. 느꼈으면..? 실행해야겠지..? 단순하게 4개의 API 호출함수의 실행시간이 각 1초가 걸린다고 가정해보자 1초 - 1초 - 1초 - 1초 = 4초 즉, 순차처리로 인하여,4초가 걸리는 것이다…

2024.12.19

© Powered by moowoo