Shirisha Gujja

BFF pattern over client-held tokens

Next.js Route Handlers proxy every backend call and hold the JWT in an httpOnly cookie. It costs an extra request hop, but it closes off the class of XSS-reads-localStorage token theft that a client-held access token is exposed to.

Session security beyond a bare JWT

Refresh token rotation, password hashing, session revocation, and automatic silent token refresh — so a session survives normal use without ever asking a user to babysit expiring tokens.

The AI coach is designed to fail without taking the app down

OpenAI calls return a typed 503 on a missing key or exhausted quota and a 502 on other upstream errors, with structured response validation — a third-party outage degrades one feature, not the whole product.

Real infrastructure caught what unit tests didn't

Running the actual Docker Compose stack surfaced an nginx route-shadowing bug, a Compose port override that silently no-op'd, and a migration that raced its own auto-migrate-on-restart — none of which a unit test suite alone would have caught.

Transactional outbox, publish-then-mark by construction

A background publisher polls unpublished outbox rows and marks a row published only after Kafka confirms delivery — so a crash between the two never produces a false 'delivered' record. Async end-to-end with aiokafka rather than the sync confluent-kafka SDK, so the whole app stays non-blocking.

Idempotency enforced in the database, not just in application logic

Alert creation is backed by a real UNIQUE(source_event_id, alert_type) constraint, verified with a test that simulates message redelivery and asserts no duplicate alert is created — closing a correctness gap that's easy to claim and easy to get wrong.

Rotating refresh tokens with theft detection

A refresh token that's presented twice — already used, or already revoked — kills its entire token family, not just the one token, so a stolen-and-replayed token can't quietly ride alongside a legitimate session.

Grounded AI insights with a real fallback

The LLM only ever sees pre-computed spend aggregates, never raw transaction rows, and a deterministic template summary — computed from the same aggregates — keeps the feature available when the API call fails or isn't configured, rather than showing an error or a mocked number.

Chaos-tested against the real stack, not reasoned about in the abstract

Killing the enrichment service mid-pipeline loses no data, because Kafka consumer-group offsets resume exactly where it left off. Stopping the Kafka broker entirely doesn't touch the request path at all, since the outbox never makes a synchronous call to it.