<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>데이터베이스 on After the Code</title><link>https://windshock.github.io/ko/tags/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4/</link><description>Recent content in 데이터베이스 on After the Code</description><generator>Hugo -- 0.145.0</generator><language>ko-KR</language><lastBuildDate>Tue, 25 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://windshock.github.io/ko/tags/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4/index.xml" rel="self" type="application/rss+xml"/><item><title>레이스 컨디션(TOCTOU) 대응: 실제 스택에서 어떤 방법이 효과가 있었나</title><link>https://windshock.github.io/ko/post/2026-08-25-race-condition-toctou-mitigation/</link><pubDate>Tue, 25 Aug 2026 00:00:00 +0000</pubDate><guid>https://windshock.github.io/ko/post/2026-08-25-race-condition-toctou-mitigation/</guid><description>구매 횟수 제한 우회, 1회뿐인 뽑기 기회의 중복 소비, 쿠폰 취소 중복 처리, 일일 리워드 한도 초과처럼 같은 check-then-act 레이스가 여러 서비스에서 반복된다. nginx + Tomcat×2 + 공유 Postgres + Redis로 실제와 비슷한 스택을 구성해 어떤 대응이 효과가 있는지 실측했다. 대부분의 단일 DB 한도 문제는 Redis 락 없이도 DB 조건부 UPDATE와 affected rows 확인만으로 막을 수 있었다.</description></item></channel></rss>