Login Broker

Purpose

Started working at BlueFCU and one of the first backend projects was deploying a login broker. The problem: the credit union was migrating from an old online banking platform to a new one, but you cannot migrate all users at once (too risky, too much can break). The login broker sat between the user and both systems, determining at login time which platform each user should be routed to, and gradually shifting the population from old to new.

Stack

What I Learned

• A login broker is a routing layer that intercepts authentication requests and decides where to send each user based on migration state. User logs in → broker checks if they have been migrated → routes to old system or new system → user never knows. The broker maintains a migration registry: a list of which users have been moved, which are in progress, and which are still on the old platform. This is the strangler fig pattern applied to authentication.
• The strangler fig pattern (named after the tree that grows around a host tree and eventually replaces it) is the safest way to migrate large systems. You do not rewrite and switch. You build the new system alongside the old one, route traffic incrementally, and slowly shift load until the old system handles zero traffic and can be decommissioned. The login broker was the fig — wrapping around the old auth system and gradually replacing it.
• Gradual migration in banking is not optional — it is a regulatory and risk management requirement. If you flip everyone to the new system and it has a bug, thousands of customers cannot access their money. By migrating in waves (1% of users, then 5%, then 20%, then 100%), you catch issues at small scale where the blast radius is manageable. Each wave is a test. Each successful wave builds confidence.
• This was fintech — real money, real compliance, real consequences. The login broker could not leak credentials between systems, could not produce auth errors that locked customers out of their accounts, and could not introduce latency noticeable to users (banking customers are impatient). The testing bar was higher than anything I had worked on before. Every edge case mattered because the edge case was someone's money.
• Java in enterprise fintech is a different world from JavaScript in a side project. Dependency injection (Spring), enterprise patterns (service layers, DAOs, DTOs), code reviews with senior engineers, deploy pipelines with staging and production environments, on-call rotations, and incident postmortems. This was where the gap between "I can code" and "I can engineer" started to close.

Key Insights

• BlueFCU was the first job where the code I wrote touched real people's lives in a way I could not ignore. A bug in a side project is annoying. A bug in a login broker for an online banking system means someone cannot pay their rent. That weight changes how you code — more tests, more defensive programming, more "what if this fails?" thinking. It is the transition from hobbyist to professional.
• The strangler fig pattern is the most important migration pattern in software, and every developer should understand it. It applies to: database migrations (dual-write to old and new, read from new, stop writing to old), API versioning (v1 and v2 coexist, clients migrate on their own timeline), frontend rewrites (new pages replace old pages one at a time), and platform migrations (exactly what the login broker did). The principle is always the same: coexist, shift incrementally, decommission when empty.
• Working in fintech — specifically at a credit union — taught me that finance is not just about money. Credit unions are member-owned cooperatives. The customers are the owners. The software serves a community, not shareholders. This ethos (serve the member, not the margin) influenced how I think about building products for real people. It is the same ethos that Potatuhs operates under — the brand serves the community.
• The Go API boilerplate fork suddenly made more sense in this context. I had been experimenting with Go for game servers, but the real-world application of backend engineering was happening in Java at a credit union. The Go experiments were not wasted — they taught me concurrency and API design. But Java at BlueFCU was where those concepts met production reality for the first time.