Authentication & Authorization
User identity, account ownership, roles, and write permission should be checked at the API boundary.
About
I implement product backends with Java/Spring Boot and Python/FastAPI. My main focus is keeping API behavior, database state, authentication, authorization, cache, and transactions aligned with service rules.
I treat AI/OCR as a backend data-boundary problem: an AI result may look valid, but it should not become final service data until the schema, review flow, and API boundary make it safe.
Backend Capabilities
State Transitions
Only valid actions should be allowed from the current state, especially for approvals, joins, and refunds.
Transactions & Locks
Shared state changes need service-layer boundaries, lock ordering, timeouts, and failure-path checks.
Cache Boundaries
I look for the paths where cache invalidation is easy to miss, not only the happy-path update.
API Contracts
Request, response, error shape, and UI expectations should be explicit enough to debug from both sides.
Database Consistency
Validation does not stop at forms; unique constraints, entity rules, and save boundaries protect invariants.
Selected Technical Cases
Cache invalidation across three execution paths
I reviewed paths where cache deletion could be skipped: before transaction commit, during exception handling, and inside async internal calls. The current direction uses transaction-aware cache handling, finally-block cleanup, async lambda cleanup, and atomic guards, while documenting the limit of local Caffeine cache in multi-instance deployments.
TransactionAwareCacheManagerProxy
Caffeine
AtomicBoolean
Two users joining the last party slot
A simple read-check-update flow can let two requests pass the capacity check. The safer design uses pessimistic locking, a fixed member-to-party lock order, and a timeout. The verified scope covers over-capacity, duplicate join, and lock-timeout behavior; full multithread load testing is still a limitation.
PESSIMISTIC_WRITE
Lock Order
Timeout
Same email, different social account ownership
Linking accounts by email alone can attach the wrong identity. The safer boundary is provider plus socialId, backed by a database unique constraint. On concurrent first signup, a unique conflict should converge by re-reading the already-created member.
provider + socialId
Unique Constraint
Re-query
Valid-looking OCR output that is still wrong
OCR response data and final receipt-save requests are separated. Optional unreadable fields can stay null, review flags and warnings keep uncertainty visible, and final save happens only after the user confirms the extracted values.
Schema Boundary
needs_review
warnings
Projects
BOUT ↗
BOUT is a receipt and warranty archive for electronics and appliances. Users upload receipt photos, get draft purchase details, and save only the values they confirm.
- Receipt/warranty archive
- Warranty expiry reminders
- OCR review
FastAPI
PostgreSQL
OpenAI API
OCR
Human Review
TFTgogo ↗
TFTgogo is a TFT community platform where players can check game information, recruit party members, and chat with participants. My work focused on login state, party capacity, duplicate joins, and chat permissions.
- Party recruitment
- Realtime chat
- Participation state validation
Spring Boot
Java
OAuth2
MySQL
Transaction
ALLPICK ↗
ALLPICK is a shopping mall platform for members, sellers, and admins. My work focused on admin and mypage flows where wrong permissions or wrong states could trigger the wrong operation.
- Admin pages
- Refund processing
- Permission/state validation
Spring Boot
JPA
MySQL
GitHub Actions
Hermes / Seohe ↗
A personal Ubuntu VPS setup for portfolio hosting, Obsidian/Jira automation, HTTPS routing, deployment restart practice, monitoring notes, and recovery-oriented operations.
- VPS operation
- Jira/Obsidian bridge
- HTTPS routing
Ubuntu
Apache
Let's Encrypt
Automation
HS
What I Build
Product Backend
Java/Spring Boot APIs for users, admins, orders, parties, account ownership, and stateful service flows.
AI Service Backend
AI/OCR result handling where generated output is reviewed, normalized, and saved only at the correct boundary.
Platform & Operations
Deployment-oriented practice with Docker, AWS, GitHub Actions, HTTPS, VPS operation, and recovery notes.
How I Work
Research
I read the current API shape, data model, issue, and failure condition before writing code.
Plan
I separate the intended change, excluded scope, expected error behavior, and verification method.
Implement & Verify
I use AI for scaffolding when helpful, then verify core logic, database state, logs, and API behavior myself.