CHUCKZ ESPAÑOLA

The problem

Bankara is a P2P digital wallet I built with a C++ backend (Drogon framework) and PostgreSQL. The core feature is simple: users can send money to each other. But I kept running into a bug during stress testing where an account would end up with a negative balance, which should never happen.

Here's what was going on. Say an account has $100. Two transfer requests come in at almost the exact same time, both trying to send $100. Both requests read the balance, both see $100, both pass the balance >= amount check. Both go through. Now the account is at -$100. That's a classic TOCTOU — Time-of-Check to Time-of-Use — race condition. The balance was valid when I checked it, but by the time I actually used it, someone else already spent it.

What I tried first

The obvious fix is locking. PostgreSQL gives you a few options here, and I went through most of them before landing on something I was happy with.

My first attempt was SELECT ... FOR UPDATE, which grabs a row-level lock on the account row. It works — it serializes access to that specific row so only one transaction can touch it at a time. But under load, it caused problems. When a lot of requests hit the same popular account, they'd all queue up waiting for that row lock. The connection pool started filling up with threads just sitting there waiting, and eventually I'd get timeouts.

Table-level locks (LOCK TABLE) were even worse. That basically makes every single transfer sequential, even for completely unrelated accounts. Not an option.

The fix: advisory locks

I ended up using PostgreSQL advisory locks, specifically pg_advisory_xact_lock. These are application-level locks that live in shared memory — they don't actually lock any rows or tables. You just pick a number, and PostgreSQL gives you a lock on that number.

The way I set it up: before doing anything with an account, I hash the account ID into a 64-bit integer using hashtext(account_id) and call pg_advisory_xact_lock on that hash. This means only one transaction can operate on a given account at a time, but transactions touching different accounts don't block each other at all.

The nice part is that these locks are tied to the transaction. When the transaction commits or rolls back, the lock is automatically released. No manual cleanup, no risk of forgetting to unlock something.

Did it work

I wrote a stress test that fires 1,000+ concurrent transfer requests at the same account. Before the fix, the account would reliably go negative. After, every single invalid transfer gets rejected correctly. Different accounts still process in parallel without blocking each other, so throughput stays fine for the normal case.

Advisory locks turned out to be a good middle ground — lighter than row locks under contention, way more granular than table locks, and the automatic cleanup on transaction end means I don't have to worry about leaked locks.

The problem

Seating-tracker is a web app I built for managing event check-ins. The main feature people actually cared about was "I just checked in, where do I sit?" — and the venue was big enough that just giving someone a table number wasn't helpful. They needed actual directions.

So I needed some kind of pathfinding. The venue has entrances, tables, stages, buffet areas, and a bunch of open floor space. People can't walk through tables. I needed to find the shortest walkable path from an entrance to any given seat and then turn that into human-readable directions like "walk straight, turn left at the stage."

How I modeled it

I treated the venue as a graph. Each important location — entrances, table centers, buffet stations, stage corners — is a node with x/y coordinates. Edges connect nodes that have a walkable path between them, weighted by Euclidean distance.

The tricky part was preventing paths from cutting through non-walkable areas. If you just connect every node to every other node, the shortest path might go straight through a table. I solved this by adding "edge nodes" along the walkable corridors. These are invisible waypoints that define where people can actually walk. The graph only has edges between nodes that have a clear line of sight along these corridors.

The pathfinding

I used Dijkstra's algorithm with a priority queue. Nothing fancy — the venue graph is small enough that performance isn't really a concern. The algorithm finds the shortest path from the nearest entrance to the guest's assigned seat.

The more interesting part was translating the coordinate path into text directions. I calculate the angle between consecutive path segments and convert that into "turn left," "turn right," or "continue straight." The directions reference landmarks ("turn left at the stage") instead of raw coordinates, which makes them actually usable.

What I learned

The edge-node system was the key insight. Without it, paths would clip through obstacles and the directions would be nonsensical. With it, the pathfinding stays clean and the directions actually match what you'd tell someone in person. The venue also supports multiple layout templates — standard tables, VIP sections, conference halls — and the graph gets rebuilt dynamically based on which template is active.

The problem

Arc-transit is a bus transit management system — fleet registration, driver management, route planning, dispatching, incident reports, maintenance tracking, the whole thing. It's a university project but I wanted to build it properly, not just dump everything into one giant package and call it a day.

The issue with most monolithic Spring Boot apps I've seen is that over time, everything ends up depending on everything else. The driver module imports something from dispatch, dispatch reaches into fleet internals, and before you know it you can't change anything without breaking three other things.

Why not microservices

Microservices would technically solve the coupling problem, but for a system this size it's overkill. I'd need separate databases, service discovery, inter-service communication, deployment pipelines for each service — all for a university project that runs on one machine. The operational complexity just wasn't worth it.

The approach: Spring Modulith

I used Spring Modulith, which gives you the module isolation of microservices but inside a single deployable application. Each business domain — fleet, driver, route, dispatch, incident, maintenance, audit, auth — lives in its own top-level package under com.transit.arctransit.

The key thing Spring Modulith does is enforce boundaries at test time. I have a ModularityTests test class that verifies the module structure. If the dispatch module tries to directly access fleet internals instead of going through the public API, the test fails. It's like having an architecture linter built into your test suite.

How it works in practice

Each module exposes a clean public API (service interfaces, DTOs) and keeps everything else package-private. Flyway handles database migrations with versioned SQL scripts, so each module's schema changes are tracked and applied in order. There's also an append-only audit log that captures every business action across all modules.

The nice thing about this setup is that if I ever needed to extract a module into its own service, the boundaries are already clean. But for now, it's one JAR, one database, one deployment — and the architecture tests keep the boundaries honest.