FlashDrop

50 dona kuponga bir vaqtda 300 ta so'rov keladi va bitta ham ortiqcha chiqmasligi kerak. Oddiy "o'qi → tekshir → yoz" mantig'i lost update tufayli 50 o'rniga 300 ta kupon chiqaradi. Bir xil biznes qoidasini 4 usulda yozib, to'g'rilik, throughput va latency o'rtasidagi muvozanatni real yuklama ostida o'lchash kerak edi.

Caddy statik frontend'ni beradi va /api/* ni Spring Boot'ga uzatadi. So'rov avval Bucket4j rate limiter'dan o'tadi (holati Redis'da). Har strategiyaning o'z endpoint'i, entity'si va jadvali bor. Redis usulida qoldiq va "olganlar" to'plami bitta Lua skriptda atomik tekshiriladi, PostgreSQL'ga yozish @Async bilan fonda.

Kattalashtirish

Nima o'zgartirildi

Birinchi jadval JIT va connection pool hali tayyor bo'lmagan bitta sovuq rundan olingan edi. scripts/bench.ps1'ga warm-up, 3 run, mediana va yaroqlilik qoidasi (muvaffaqiyatli + sold out < 300 bo'lsa yaroqsiz) qo'shilib, qayta o'lchanganda ikki xulosa teskari bo'ldi: lock'siz usul "eng sekin" emas, "tez, lekin noto'g'ri" (80.4 → 307 rps), optimistic lock esa "eng sekin" emas, FOR UPDATE'dan 1.76 marta tez (114.1 → 331 rps). Sababi: findByCodeForUpdate qoldiqni tekshirishdan oldin qulf oladi. Yaxshilash (qulfdan oldin oddiy SELECT bilan sotuv tugaganini tekshirish) hali qilinmagan.

Belgi

2026-10-09 deploy'dan keyin flashdrop.javohir.dev'da UI buzildi, sahifada xom <<<<<<< HEAD matni chiqdi.

Sabab

Lokal repo GitHub'dan orqada qolgan edi. Push rad etilgach git pull merge'ida 4 ta faylda conflict chiqdi va belgilar tozalanmasdan commit qilindi. Frontend Caddy orqali git ishchi papkasidan berilgani uchun git pull bilan darhol production'ga chiqdi; backend rollback'i esa frontend'ni qamramadi.

Yechim

frontend/index.html oxirgi ishlagan commit'dan tiklandi, README'lar qayta yozildi, tasodifan commit bo'lgan IDE build natijasi (bin/) olib tashlanib .gitignore'ga qo'shildi va qayta deploy qilindi (7ac0754).

Takrorlanmasligi uchun

deploy.sh endi git grep bilan upstream'da conflict belgisi bormi tekshiradi va topsa deploy'ni to'xtatadi, merge faqat --ff-only bilan (a2dd204). Yashirin oqibat ham topildi: conflict tuzatilganda README'lar (ko/en/uz) eski sovuq run jadvaliga qaytib qolgan edi; portfolio matnini repo bilan solishtirganda topilib, qayta o'lchangan natijalar tiklandi (a29c567).

Testlar soni

4

Qamrov

—

CI

—

Test vositalari

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

Deploy muhiti

iwinv VPS, Docker Compose: app (Spring Boot, root bo'lmagan, 1 GB xotira cheklovi), web (Caddy: statik konsol + /api/* proxy), PostgreSQL 17, Redis 7, seed (demo kampaniyalar). Postgres va Redis portlari ochilmagan. deploy.sh: conflict belgisi tekshiruvi → git merge --ff-only → image SHA tegi bilan ham build → app va web yangilanadi, SHA .deploy-history'ga yoziladi. HikariCP 50, Tomcat accept-count 500.

Backup

Kunlik pg_dump (03:00 KST, cron), 7 kun saqlanadi, serverdagi 9 ta Postgres bazasini qamraydi. 2026-10-09 03:00 da avtomatik bajarilgani tasdiqlangan. Tiklash sinalgan: FlashDrop 0.22 s (11/11 jadval), LedgerCore 0.66 s (14/14)

Rollback

rollback.sh oldingi SHA image'ini latest qilib, build'siz app'ni qayta yaratadi. Production'da buyruq real 0m1.201s, tashqaridan kuzatilganda 03:32:00–03:32:07 oralig'ida 502, keyin yana 200.

Monitoring

pg_stat_statements yoqilgan, DB PG Insight'ga monitoring tarmog'i orqali ulangan

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

  Ataylab qilingan lost update: qulfsiz o'qish → tekshirish → yozish

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

  @Lock(PESSIMISTIC_WRITE) bilan findByCodeForUpdate

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

  Self-invocation'ni chetlab o'tish uchun alohida bean'ga chiqarilgan tranzaksiya

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

  Dublikat, qoldiq va kamaytirish bitta atomik amalda

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

  Lua natija kodlarini biznes statuslarga aylantiradi va DB yozuvini fonga uzatadi

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

  Postgres'ga @Async bilan keyin yozish

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

  Bucket4j + Redis token bucket, 429 va Retry-After

• scripts/bench.ps1

  Warm-up, 3 run, mediana, yaroqsiz runni qayta yugurish

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

  Conflict guard, SHA-tagli image, rollback

Lock'siz usul 50 o'rniga 300 ta kupon berdi (remaining_quantity 0 emas, 46 da qoldi), qolgan uch strategiya 300 so'rovdan aniq 50 tasini o'tkazdi va DB'da ham aynan 50 ta yozuv qoldi. Redis FOR UPDATE'ga nisbatan throughput bo'yicha 4.6, p95 bo'yicha 8.2 marta yaxshi chiqdi. Raqamlar 1 warm-up'dan keyingi 3 ta yaroqli run medianasi; muvaffaqiyatli + sold out yig'indisi 300 dan kam bo'lgan runlar (TCP backlog tufayli qisman rad etilgan) avtomatik yaroqsiz deb belgilanib, qayta yugurildi. Rate limit: bitta userId bilan 12 so'rovdan 6 tasi o'tdi, 6 tasi 429 (5 token + greedy refill).