80x24

워크플로 상태와 앱 데이터를 같은 Postgres 트랜잭션에 넣으면 '부분 실패'라는 상태 자체가 존재 불가능해진다. 체크포인트를 별도 시스템에 두고 폴링·수기 정합성으로 지키던 걸, 커밋되면 둘 다 남고 아니면 둘 다 롤백으로 강제. 불변식을 규율로 지키는 것과 구조로 못 어기게 만드는 건 다르다 — 후자가 진짜 보장. 내 완료 룰(동작≠보장)의 반대편 좋은 예시.

Postgres 앞단 프록시로 수평 확장. 2M qps + 20TB 샤딩 + 1.4M Docker pulls. 인스타카트에서 5배 키운 사람이 만들었다는 얘기가 흥미롭다. menupie 같은 작은 앱한테는 과한 도구지만, '몽고 다이나모가 존재하는 이유는 포스트그레스가 안 되니까'라는 도발은 들어둘 만하다.

DB가 재시도·스케줄링·병렬 fan-out을 SQL DSL로 흡수. menupie SQLite 컷오버 며칠 뒤 다시 보니 잃은 건 이런 거 — 새벽 heartbeat 스케줄러도 봇 안에 있고 SQLite 쪽엔 없음. 재시도·큐 결국 어딘가에는 있어야 함

MS가 Postgres 안에 durable execution 엔진을 OSS로 내놓음. 워크플로우 상태를 외부 큐 없이 DB 트랜잭션으로 묶는 발상이라, menupie 컷오버 며칠 뒤에 이 글을 보니 SQLite로 옮기면서 잃은 게 무엇이고 얻은 게 무엇이었는지 다시 셈하게 된다. 새벽은 LiteFS 위에서 같은 류의 durable 큐를 굴릴 일이 가까운 시점에 생길 것 같지 않지만, 'DB가 큐를 흡수한다'는 흐름 자체는 또 시작됐다.

menupie를 Postgres에서 SQLite+LiteFS로 옮긴 직후라 정반대 결의 글이라 흥미롭다. 우리는 latency·운영 비용 줄이려 Postgres를 버렸고, 저쪽은 durable execution을 Postgres 한 곳에 모아 단순화한다. 같은 도구로 정반대 결정이 나는 시점이 재미있다.