Why exact decimals?
No rounding ambiguity. The backend calculates with BigDecimal; the UI displays returned strings.
Synthetic USDVerified CI ↗
THE AUTOMATION COMMAND CENTER
Financial logic.
Executable proof.
A working credit-card ledger, independently tested through Java and Cucumber. Explore the behavior, inspect the contracts, follow the evidence.
Java 21Spring BootCucumberREST AssuredPostgreSQL
CF / ENGINEERING LEDGER01
Every state change
has a receipt.
has a receipt.
01
Validate the contractExact decimal input
↗02
Commit atomicallyBalance + immutable ledger
↗03
Prove the behaviorIndependent HTTP assertions
↗01 / BANKING SIMULATOR
Exercise the real system.
Fresh synthetic data for your session. Changes persist until its 30-minute expiry.
Start a private synthetic account to exercise the real API.
Credit limit—USD / fixed synthetic limit
Outstanding balance—Posted purchases − payments
Available credit—Limit − outstanding balance
Session account
NOT STARTEDYour isolated account
Start an account to see live balances and transaction history.
Credit utilization—
AUTHENTICATIONAccount-scoped, expiring session
DATA SOURCELive API → PostgreSQL
Transaction ledger
NEWEST FIRST / UP TO 50 ENTRIES| Sequence | Operation | Amount | Balance after | Posted at |
|---|---|---|---|---|
| Start a synthetic account to view its ledger. | ||||
02 / API EXPLORER
Contracts you can inspect.
Versioned endpoints, structured errors and explicit request identity.
POST
/api/v1/accounts/{id}/paymentsAuthorization: Bearer <session-token>
Idempotency-Key: payment-001
Content-Type: application/json
{ "amount": "50.00" }Representative request. Amount is a decimal string. Initial post: 201. Identical replay: 200. Conflicting key: 409.
Latest transaction response
LIVE SESSION// Submit a transaction to inspect // its actual response here.
03 / TEST AUTOMATION & CI
Follow a rule through every layer.
Execution reports live with the exact source commit. No invented pass history.
01
Domain unit tests
Money precision, immutable state and credit boundaries.
Inspect implementation ↗02PostgreSQL integration
Persistence, rollback, constraints, replay and concurrent updates.
Inspect implementation ↗03Independent Cucumber
Gherkin → scenario context → REST Assured → running API.
Inspect implementation ↗04Enterprise tooling
Separate TestNG matrix, Bruno collection and Jenkins pipeline.
Inspect implementation ↗Read an executable scenario
Scenario: Concurrent requests cannot overspend available credit When I submit 12 simultaneous purchases of "100" Then exactly 7 responses have status 201 And exactly 5 responses have status 422 And the account has outstanding "950.00" and available "50.00" And there are 7 ledger entries
Source and CI links are pinned to verified implementation 20c91f5. See the current evidence record for later runs and limitations, including Jenkins server execution. Authored configuration is not execution proof.
04 / ARCHITECTURE & DECISIONS
Small system. Explicit boundaries.
VISITORNext.js command centerHttpOnly session · same-origin writes
→APPLICATIONSpring Boot ledgerOwnership · validation · row locks
→PERSISTENCEPostgreSQLAtomic state + receipt · Flyway
Why row locks?
Concurrent operations serialize per account. The credit check and ledger entry share one transaction.
Why independent tests?
API automation imports no application classes, so it validates observable contracts rather than implementation details.
05 / THE FIVE-MINUTE WALKTHROUGH
Run it. Explain it.
Rebuild the important parts.
Domain rules → transactional service → Cucumber architecture → execution evidence → trade-offs.
Open the interview guide ↗BUILT TO BE DEFENDED
This portfolio project was built with AI assistance. The interview goal is to understand, reproduce and debug the engineering personally.