Ragavarshini R

Senior Software Engineer, PayPal  ·  Chennai, India  ·  9+ years

I build systems whose guarantees don't depend on the caller behaving.

Reading as
Summary

The short version

Nine years building low-latency distributed systems for fintech and enterprise SaaS. Java and Spring Boot, REST and GraphQL, event-driven architecture on Kafka, query optimization under high traffic, and zero-downtime migrations on platforms serving millions of users.

Currently shipping checkout services and production agentic tooling at PayPal. On my own time I build ledgers where correctness is enforced by the schema rather than the service — because a rule in the schema binds every caller, including the ones nobody wrote yet.

Nine years owning features end to end — React and Next.js interfaces, Java/Spring and Node services, the event pipelines and databases underneath. At PayPal that means checkout: interface through to API, for platform releases adopted across 52+ EU countries.

I also build the tooling the team uses to see what checkout is doing — Datadog and BigQuery diagnostics, and an agent that reads them in natural language. The most useful full-stack work is usually the part nobody asked for but everybody uses.

Nine years setting technical direction for high-scale platforms. I take capability areas from prototype to team adoption — most recently production agentic AI — set standards that outlive the project, and drive rollouts across international markets.

What I care about most is where a guarantee lives. A constraint in the schema binds the service, the migration script, the bulk importer, and the engineer with a psql prompt at 2am. A check in a service binds one caller. The same question applies to agents: bind one tool to a crew and it cannot call outside its route; ask the model nicely and eventually it won't.

Selected work

Five systems, and the decisions behind them

Each entry is split the way the work actually was — first the constraint that shaped it, then what I decided to do about it.

Personal 2026

Double-entry payments ledger with a read-only MCP server

payments-ledger-mcp ↗

Constraint

A double-entry ledger is only useful if it cannot go out of balance. Application-layer checks bind only the code paths that remember to call them — a migration script, a bulk importer, or a psql session at 2am walks straight past all of them.

Separately: an AI agent investigating a discrepancy needs to read the ledger, and must never be able to write to it.

Decisions

  • Five invariants pushed into PostgreSQL, not the service — so the database is what refuses a bad write, whoever issues it.
  • Amounts as BIGINT minor units with a separate direction column. No decimal type, no rounding drift, no currency-scale guessing.
  • Corrections by reversal only. Never UPDATE or DELETE — post the mirror transaction, so the mistake and the fix both stay in the audit trail.
  • Idempotency by request fingerprint. SHA-256 of the canonicalized body: replay the same key with a different payload and you get a 409, not a silent success returning someone else's transaction.
  • The MCP server holds no database credentials. It calls read-only HTTP endpoints — the same boundary any external consumer faces — and exposes four tools: get_balance, list_transactions, trace_transaction, find_imbalances. Every response carries the exact request it made, so an answer can be checked.
  • Tested against real PostgreSQL via Testcontainers, never H2. An invariant contract test attacks each rule through raw SQL, bypassing the service entirely, to prove it's the database doing the refusing.
The five invariants, and where each one is enforced
InvariantEnforcement
Zero-sumDebits equal credits per transaction — DEFERRABLE INITIALLY DEFERRED constraint trigger, checked at commit
IdempotencyUnique constraint on the key, plus insert-and-catch; the conflict loser re-reads the winner in a fresh transaction
Append-onlyBEFORE UPDATE OR DELETE trigger on ledger entries — there is no path that mutates history
Derived balancesNo stored balance column; balances compute from entries on every read via SQL views
AtomicityAll legs of a transaction commit together or not at all, verified at commit time
AI agent any MCP client MCP server no DB credentials 4 read-only tools Ledger service Java 21 · Spring Boot PostgreSQL 5 invariants triggers · views MCP HTTP GET JDBC TRUST BOUNDARY — writes are unreachable from the left of this line
The agent reaches the ledger through the same read-only door as any other external consumer.
Tradeoff taken No raw-SQL MCP tool, deliberately. It would be the most flexible tool on the server, and it would move the trust boundary from the API to the model's judgment. Also out of scope: auth, multi-currency and FX, a UI, and real payment rails. A small ledger with airtight guarantees is worth more than a sprawling one with soft ones.
Stack  Java 21 · Spring Boot 3 · PostgreSQL 16 · Liquibase · Python (MCP SDK) · JUnit 5 · Testcontainers
Personal 2026

Agentic RAG router with structurally bound tools

AIProjects ↗

Constraint

A router agent that should only use the right tool will eventually use the wrong one. Prompt instructions are not an access control mechanism.

CrewAI's sequential process also has no native conditional branching — so there was no framework-supported way to pick a path and commit to it.

Decisions

  • Two crews, not one. A router crew classifies the question. The retriever-and-answer crew is constructed afterwards, with exactly one tool bound to it — so the agent physically cannot call a tool outside its route.
  • Branching in plain Python between the crews, not in a prompt. The framework didn't offer it, so the control flow lives where control flow belongs.
  • Retrieval and answer generation as separate chained tasks, so each agent output is inspectable, and the answer agent is constrained to the retriever's evidence. Out-of-scope questions return an explicit refusal rather than a confident invention.
  • A full reasoning trace per run to CSV: question, chosen route, router reasoning, tool used, retrieved evidence, final answer. Routing decisions you can't audit are routing decisions you can't tune.
  • Wrapped LangChain's Tavily search in a CrewAI BaseTool subclass to pass tool validation, and moved the pipeline onto kickoff_async so it runs inside the Jupyter event loop.
Question natural language Router crew classify only Python branch not a prompt Crew + PDF search 1 tool bound Crew + web search 1 tool bound Crew, no tool direct answer Answer + CSV trace
The route is decided before the crew exists, so the crew has no wrong tool to reach for.
Tradeoff taken Constructing the crew after routing costs a little startup time on every query and rules out mid-run route changes. In exchange, tool misuse stops being a prompt-engineering problem and becomes structurally impossible.
Stack  Python · CrewAI · GPT-4o-mini · Tavily · LangChain · FAISS · pandas   Also in this repo  a fully local RAG pipeline (Ollama, ChromaDB, Tesseract OCR — no cloud API), and an AutoGen analysis service on FastAPI wired into n8n with a mock mode for offline runs
PayPal 2025–

Multi-agent pipeline for conversion diagnostics

internal · no public repo

Constraint

“Why did conversion dip in DE last week?” was a question that cost an engineer hours. Pull the numbers from BigQuery, find the funnel step that moved, then start joining event tables and Datadog logs by hand — and the knowledge of which query answers which symptom lived in a handful of people's heads.

The same question arrives scoped three different ways — by country, by merchant, or by experiment — and a good share of the time the answer is something the team has already seen before and written up.

Decisions

  • Check before diagnosing. The pipeline pulls conversion for the requested scope from BigQuery first and stops there if nothing moved. No dip, no investigation — the cheapest possible answer is “nothing happened”.
  • Escalate in tiers, cheapest first. A diagnostic agent localizes the dip to a checkout section from the drop-off funnels. An analyzer agent then runs a fixed set of queries — one set per known problem type — against that section.
  • Open-ended search only when the deterministic tiers come up empty. If the analyzer's output doesn't point at a specific problem, a hypothesis agent takes over: event tables, Datadog, and call logs, within a bounded search surface.
  • Institutional knowledge as a retrieval corpus. The hypothesis agent references a library of past analysis documents, so a recurring issue is recognized rather than re-investigated from scratch. “We've seen this before” stops being a hallway conversation.
  • A report agent closes it out — the numbers, the conversion movement, the drop-off level, and the cause with the stats behind it. The output is something you can send to a merchant or a stakeholder, not a chat transcript someone has to summarize.
  • Tool access through typed MCP servers over BigQuery and Datadog: read-only and scoped at the server layer, with argument validation and structured errors, so agents fail loudly instead of inventing results — and credentials never enter an agent's context.
EACH TIER IS SLOWER AND LESS DETERMINISTIC THAN THE ONE BEFORE IT Question conversion, scoped BigQuery fetch dip, or no dip Diagnostic which funnel step Analyzer known-issue queries Report numbers + cause Hypothesis agent event tables · Datadog · call logs + library of prior analyses if dip if found if inconclusive cause
Scope is always a country, a merchant, or an experiment. The pipeline only pays for the next tier when the previous one couldn't answer.
Tradeoff taken The hypothesis agent is deliberately last and deliberately bounded. It's the only tier that searches openly — which makes it the slowest, the most expensive, and the one most capable of producing a confident wrong answer. So it runs only after the deterministic tiers have failed, and its search surface is capped rather than left to the model's discretion.
Stack  Python · multi-agent orchestration · MCP SDK · BigQuery · Datadog API
PayPal 2025–

Checkout, across 52+ EU countries

Constraint

Checkout changes ship to more than 52 European markets at once. Every additional authentication step costs conversion; every regression is measured in real transactions, not in test coverage.

And you cannot fix funnel leakage you can't see — detection time is part of the problem, not separate from it.

Decisions

  • Delivered the full path — React, Next.js and TypeScript interfaces through Java/Spring and Node.js services over REST and GraphQL — for platform versions adopted across 52+ EU countries.
  • Re-engineered Amex delegation flows to cut authentication overhead out of the user journey, raising transaction success rates.
  • Owned conversion strategy for enterprise merchants end to end: found the friction points across checkout, prioritized the fixes, and drove them through to release rather than filing them.
  • Led performance optimization of the checkout module, delivering measurable conversion gains alongside latency reduction.
  • Built automated real-time conversion monitoring and custom Datadog reporting, cutting the time to identify production funnel leakage.
  • Architected the agentic diagnostic system over BigQuery and Datadog that autonomously surfaces root causes of user drop-offs.
  • Scrum Master for the team — running Agile ceremonies and raising delivery predictability.
Stack  Java · Spring Boot · Node.js · React · Next.js · TypeScript · REST · GraphQL · BigQuery · Datadog
Zoho 2017–2025

Eight years of scale work on a healthcare EHR platform

Constraint

A platform serving millions of users against 99.9% uptime SLAs, in healthcare, where a maintenance window is not something you get to ask for.

And a distributed system whose services each logged differently — which meant every incident started with an archaeology phase before anyone could start debugging.

Decisions

  • Zero-downtime database migrations on a platform serving millions of users, with no customer-visible impact. Treated as a design problem up front, not a maintenance window to negotiate.
  • Scalability work on the Marketplace framework, cutting query execution time by 25%.
  • Low-latency redesign of encounter functionality, improving system responsiveness and stability by 30%.
  • Introduced Apache Kafka for asynchronous, event-driven communication and real-time webhook processing across services.
  • Standardized logging across distributed services — MTTR down 20% team-wide. This is the one I'd point at: it wasn't a feature, it was a convention everyone adopted, and it outlived every project it touched.
  • Set query optimization and load-management practice for high-traffic paths, sustaining the 99.9% uptime SLA.
  • Owned critical dependency and framework upgrades holding the platform's security and performance baselines.
Stack  Java · Spring Framework · Struts · Apache Kafka · Zookeeper · MySQL · MongoDB · Kibana
Also on GitHub

Smaller builds, each one a specific problem

Not portfolio pieces so much as places I went to learn one thing properly.

ecommerce ↗

Delivery-platform REST API with a PostGIS radius search for nearby addresses. QueryDSL for type-safe queries; Liquibase owns the schema with Hibernate auto-DDL switched off, so the migration file is the truth.

Java 21 · Spring Boot 3 · PostgreSQL + PostGIS

CinemaBooking ↗

Seat booking with deterministic conflict resolution: Redis holds a transient per-show queue, requests aggregate for one second, then resolve FIFO so overlapping seat claims are rejected rather than raced. Payment runs on its own thread with a 120-second timeout so it never holds a servlet request thread.

Java · JAX-RS · MySQL · Redis

flightbooking ↗

A monolith and its decomposition, side by side. Split into EntityService (shared JPA domain library), UserService, FlightService and BookingService, with REST inter-service calls, Docker Compose, and Kubernetes manifests for Minikube.

Spring Boot · MySQL · Docker · Kubernetes

health-record ↗

Permissioned health records on Ethereum. onlyAdmin and onlyDoctors modifiers enforce roles at the contract level, every state change emits an event, and three web3.js consoles cover admin, doctor and patient. The README is honest about what blockchain costs here.

Solidity · Ethereum · web3.js
How I work

Six things I keep coming back to

Put the guarantee where it binds everyone

A constraint in the schema binds the service, the migration, the bulk importer, and the person at a psql prompt. A check in a service binds one caller — the one that remembered to call it.

Constrain agents structurally, not by instruction

Bind one tool to the crew. Scope the credentials at the server. Leave the dangerous tool off the server entirely. Prompt instructions describe intent; they don't enforce it.

Migrations are a design problem, not a maintenance window

If the plan requires downtime, the plan isn't finished. On a healthcare platform serving millions, the window was never going to be granted anyway.

Observability is a standard, not a ticket

One beautifully instrumented service doesn't cut MTTR. A logging convention the whole team follows does — and it keeps paying out long after the project that prompted it.

Show the query you ran

Whether it's an agent answering a question or an engineer claiming a regression: an assertion someone can verify is worth more than a confident one they can't.

Test against the real thing

Testcontainers with real PostgreSQL, not H2. If the point is proving the database refuses a bad write, a substitute that behaves differently proves nothing.

Technical

What I work in

Languages

Java · Python · TypeScript · JavaScript · SQL · Solidity

Backend & APIs

Spring Boot · Spring Framework · Struts · Node.js · Express · JAX-RS · REST and GraphQL design · microservices · event-driven architecture

Data & Messaging

PostgreSQL · MySQL · MongoDB · BigQuery · Redis · Apache Kafka · Zookeeper · query optimization · zero-downtime migrations · Liquibase

Frontend

React · Next.js · TypeScript · JavaScript · HTML5 · CSS3

Agentic AI

MCP server design · agentic RAG and retrieval routing · CrewAI · AutoGen · LangChain · multi-agent orchestration · tool binding and guardrails · FAISS · ChromaDB · Pinecone · Ollama · LangSmith

Infrastructure & Delivery

Docker · Kubernetes · Jenkins · Maven · Gradle · Git · Bitbucket · Testcontainers · JUnit 5

Observability

Datadog · Kibana · distributed tracing · production diagnostics · SLA and latency monitoring

Leadership

Technical strategy · architecture review · cross-team rollout · mentoring · Scrum Master · stakeholder and enterprise-customer engagement

Credentials

Education & certification

M.Tech

Software Engineering — BITS Pilani

B.Tech

Information Technology — Karpagam College of Engineering, Coimbatore

Certification

Professional Certificate Program in Blockchain — IIT Kanpur

Certification

Applied Agentic AI: Systems, Design & Impact — Microsoft & Simplilearn