Quick Story
Built as part of a backend engineering assessment. Completed in ~30 hours before travel commitments.
The company later turned out to be collecting submissions rather than hiring, but the project became one of my strongest learnings in idempotency and transaction systems.
Overview
FinTech Core API was built as part of a backend engineering assessment.
The goal was to design transaction APIs with reliability, concurrency protection, idempotency, and auditability in mind.
Technical Decisions & Tradeoffs
1. Mutex Locking
Implemented mutex locking using local process memory.
Why?
The assessment timeline was limited, and I wanted to focus on demonstrating the concept rather than building distributed infrastructure.
Limitation
This solution works only for a single application instance.
In a horizontally scaled environment, multiple instances would not share the same lock state.
Production Alternative
Redis-based distributed locking.
Lesson
Engineering decisions should be made relative to business requirements, timelines, and constraints.
2. Idempotency Strategy
Implemented idempotency protection for transaction requests.
Decision
Cached only successful transaction responses.
Why?
If a transaction fails due to a temporary issue, the client should be able to retry the request.
Caching failed responses would prevent legitimate retries.
Benefit
Supported safe retry behavior while preventing duplicate successful transactions.
3. Idempotency Key Placement
Stored idempotency keys in request headers instead of request bodies.
Reasoning
I wanted a clear separation of concerns:
Headers → Metadata
Body → Business Data
Benefit
Improved API design consistency.
4. Mutex Check Before Database Calls
Checked mutex locks before executing database queries.
Why?
There is no reason to query the database if the request is already blocked by a lock.
Benefit
Reduced unnecessary database operations and improved efficiency.
Challenges & Mistakes
Started Coding Before Designing
The biggest mistake I made during the assessment was starting implementation before fully defining:
API contracts. Architecture. Request flow. Data flow.
Impact
This led to:
Rewrites. Refactoring. Confusion during implementation. Lost development time.
Lesson
Spending time on architecture and API design before implementation saves significant effort later.
What I Learned
Idempotent Replay Responses
Learned how clients can identify whether a response originated from:
New Request
or
Previously Processed Request
using replay metadata.
Financial System Design
While researching transaction systems, I learned why financial applications often prefer:
Soft Deletes. Audit Trails. Data Integrity Controls.
over direct data removal.
Write-Through Cache
Learned how write-through caching strategies are used to maintain consistency between cache and database layers.