`SQLite`만으로 내구성 있는 워크플로 구현 가능

// related

• #0001

  #0001인프라·SaaSGeekNews15시간 전

  `Shopify`, 재고 예약 시스템을 Redis에서 MySQL로 교체

  `Shopify` Replaces Redis Inventory Reservations With MySQL

  50radar

  Shopify전자상거래 SaaS — 결제·스토어 운영 통합

  캐시성 예약을 트랜잭션 행 잠금으로 옮겨 오버셀 방지를 단순화했다. 결제 정확성이 카운터 성능보다 중요한 한정 재고 서비스라면 참고할 만함.

  • —MySQL 8의 SKIP LOCKED로 이미 잡힌 행을 건너뛰며 예약 처리. 결제 중 경합이 큰 상품에서 대기열 병목을 줄인다.
  • —수량 컬럼 하나를 줄이는 대신 판매 단위당 1개 행으로 모델링. 테이블은 커지지만 잠금·복구 의미가 더 명확해진다.
  • —티켓, 예약, 한정판 판매처럼 오버셀이 치명적인 흐름에 맞다. 소규모 상품몰은 카운터와 멱등 주문 검증으로도 충분하다.

  출처: news.hada.io/topic?id=30006원문 보기 →
• #0002

  #0002인프라·SaaSGeekNews16시간 전

  컨테이너 레지스트리 내부 구조로 `Push/Pull` 디버깅하기

  How Container Registries Work: Push/Pull Images Directly

  40radar

  docker push 뒤에서 태그·매니페스트·레이어가 어떻게 묶이는지 알아야 배포 장애를 빨리 좁힌다. 작은 서비스도 컨테이너로 배포한다면 실전 디버깅 가치 있음.

  • —레지스트리는 콘텐츠 주소 지정 blob 저장소다. 레이어는 digest로 참조되며, blob 누락 시 태그가 있어도 pull이 깨진다.
  • —태그는 고정 버전이 아니라 바뀔 수 있는 포인터다. 재현 가능한 배포에는 latest보다 이미지 digest 고정이 안전하다.
  • —플랫폼 불일치는 매니페스트 메타데이터에서 터진다. 로컬 ARM 빌드를 x86 서버에 올릴 때 먼저 확인해야 한다.
  • —삭제도 단순하지 않다. 태그 제거와 실제 blob 정리는 다르며, 레지스트리 GC 동작까지 봐야 저장공간이 줄어든다.

  출처: news.hada.io/topic?id=30004원문 보기 →
• #0003

  #0003인프라·SaaSGeekNews17시간 전

  `Postgres`로 내구성 워크플로 구축하기

  Building Durable Workflows on `Postgres`

  50radar

  실행 상태를 DB에 체크포인트하면 장애 뒤 마지막 완료 단계부터 재개할 수 있다. 이미 Postgres를 쓰는 작은 SaaS라면 오케스트레이터 추가 전 검토할 만함.

  • —내구성 워크플로는 각 단계 완료 상태를 저장해, 충돌 후 전체 재실행 대신 완료 지점 다음부터 이어간다.
  • —Temporal, Airflow, AWS Step Functions 방식은 중앙 오케스트레이터와 저장소가 늘어 운영 복잡도가 커진다.
  • —Postgres 기반 접근은 결제 후처리, 이메일 발송, 데이터 임포트, LLM 배치 작업처럼 재시도가 중요한 백엔드에 잘 맞는다.

  출처: news.hada.io/topic?id=29999원문 보기 →