FlashDrop

Three hundred concurrent requests hit 50 coupons, and not a single extra coupon may be issued. A plain read, check, write flow issues 300 coupons instead of 50 because of lost updates. I implemented the same business rule four ways to measure the balance between correctness, throughput and latency under real load.

Caddy serves the static frontend and forwards /api/* to Spring Boot. Requests first pass a Bucket4j rate limiter whose state lives in Redis. Each strategy has its own endpoint, entity and table. The Redis strategy checks the remaining count and the set of users who already claimed inside one Lua script, and writes to PostgreSQL in the background with @Async.

View larger

What changed

The first table came from a single cold run before the JIT and the connection pool had warmed up. Adding warm-up, three runs, a median and a validity rule (success + sold-out < 300 means invalid) to scripts/bench.ps1 and re-measuring overturned two conclusions: no-lock was not 'slowest' but 'fast and wrong' (80.4 → 307 rps), and the optimistic lock was not 'slowest' but 1.76x faster than FOR UPDATE (114.1 → 331 rps). The reason is that findByCodeForUpdate takes the lock before checking the remaining count. The fix (a plain SELECT to check sell-out before locking) is not applied yet.

Symptom

After a deploy on 2026-10-09 the flashdrop.javohir.dev UI broke and the page showed a raw <<<<<<< HEAD marker.

Root cause

The local repository was behind GitHub, so the push was rejected; the git pull merge conflicted in four files and the markers were committed unresolved. Caddy served the frontend straight from the git working directory, so the pull went live immediately, and a backend rollback could not undo it.

Fix

Restored frontend/index.html from the last working commit, rewrote the READMEs, removed accidentally committed IDE build output (bin/), added it to .gitignore and redeployed (7ac0754).

Prevention

deploy.sh now uses git grep to scan upstream for conflict markers and stops the deploy if it finds any, and merges only with --ff-only (a2dd204). A hidden side effect turned up too: while fixing the conflict, the READMEs (ko/en/uz) had reverted to the old cold-run table; I caught it when comparing the portfolio text with the repo and restored the re-measured results (a29c567).

Tests

4

Coverage

—

CI

—

Test tools

JUnit 5, Testcontainers (PostgreSQL 17, Redis 7), virtual threads, k6, bench.ps1

Deployment

iwinv VPS on Docker Compose: app (Spring Boot, non-root, 1 GB memory limit), web (Caddy: static console + /api/* proxy), PostgreSQL 17, Redis 7 and seed (demo campaigns). Database and Redis ports are not exposed. deploy.sh: conflict-marker check → git merge --ff-only → build the image with a SHA tag too → update app and web, recording the SHA in .deploy-history. HikariCP 50, Tomcat accept-count 500.

Backups

Daily pg_dump by cron at 03:00 KST, kept for 7 days, covering all 9 Postgres databases on the server. The 2026-10-09 03:00 run was confirmed. Restore tested: FlashDrop 0.22 s (11/11 tables), LedgerCore 0.66 s (14/14 tables)

Rollback

rollback.sh points latest at the previous SHA image and recreates the app without building. In production the command took real 0m1.201s; seen from outside, it returned 502 from 03:32:00 to 03:32:07 and then 200 again.

Monitoring

pg_stat_statements enabled; the database is connected to PG Insight over the monitoring network

• src/main/java/com/flashdrop/strategy/nolock/NoLockClaimService.java

  A deliberate lost update: read, check, write without locks

• src/main/java/com/flashdrop/strategy/forupdate/ForUpdateCampaignRepository.java

  @Lock(PESSIMISTIC_WRITE) findByCodeForUpdate

• src/main/java/com/flashdrop/strategy/optimistic/OptimisticClaimAttempt.java

  The transaction moved into its own bean to avoid self-invocation

• src/main/resources/scripts/claim.lua

  Duplicate check, remaining count and decrement in one atomic operation

• src/main/java/com/flashdrop/strategy/redis/RedisClaimService.java

  Maps Lua result codes to business statuses and hands the database write to the background

• src/main/java/com/flashdrop/strategy/redis/RedisClaimWriteBackService.java

  Writes to Postgres later with @Async

• src/main/java/com/flashdrop/ratelimit/RateLimitInterceptor.java

  Bucket4j + Redis token bucket with 429 and Retry-After

• scripts/bench.ps1

  Warm-up, three runs, median, rerunning invalid runs

• scripts/deploy.sh, scripts/rollback.sh

  Conflict guard, SHA-tagged images, rollback

The no-lock version issued 300 coupons instead of 50 (remaining_quantity stayed at 46, not 0), while the other three let exactly 50 of 300 requests through, leaving exactly 50 rows in the database. Redis beat FOR UPDATE by 4.6x on throughput and 8.2x on p95. Figures are the median of three valid runs after one warm-up; runs where success + sold-out added up to fewer than 300 (some requests refused by the TCP backlog) were marked invalid automatically and rerun. The rate limit let 6 of 12 requests from one userId through and answered 6 with 429 (5 tokens + greedy refill).