Ragavarshini R

Senior Software Engineer, PayPal  ·  Chennai, India  ·  9+ years
Backend · Distributed Systems · Event-Driven Platforms Full Stack · Checkout Systems · Interface → API → Data Technical Direction · Platform Architecture · Production AI Systems

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

Reading as
Summary

The short version

Amex delegation conversion, after removing an authentication stepPayPal
30%Conversion lift on the new checkout version, across the EU markets it shipped toPayPal
52+EU countries ramped to the new checkout version — ~95% of EU trafficPayPal
Weeks → hoursConversion analysis turnaround, after internal toolingPayPal
99.9%Uptime SLA sustained, platform serving millions of usersZoho
20%MTTR reduction, team-wide logging standardZoho

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 on high-scale platforms, most of it spent setting their technical direction. Standards the whole team adopted, an architecture pattern that outlived the project that prompted it, and capability areas taken from prototype to team adoption — most recently production agentic AI — alongside rollouts driven 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.

Experience

Where I’ve worked, and the decisions behind it

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

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 the platform versions now live across 52+ EU countries.
  • Ramped the new checkout version country by country to 52+ EU markets, now carrying roughly 95% of EU checkout traffic. Conversion was watched at each step of the rollout, not totalled at the end of it.
  • Re-engineered Amex delegation flows to cut a full authentication step out of the user journey — 4× improvement in delegation conversion.
  • 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 — conversion on the new checkout version up 30% across the EU markets it shipped to.
  • Led performance optimization of the checkout module, cutting latency on the critical path — measured release by release against the conversion numbers, not asserted afterwards.
  • Built the internal conversion tooling — automated real-time monitoring and custom Datadog reporting — taking conversion analysis from one to two weeks of manual investigation down to a few hours, and funnel leakage from something you went looking for to something that surfaces on its own.
  • 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
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
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
Influence

Four things that outlived the project that prompted them

The work I point at first is rarely a feature. It is usually a pattern other services ended up built on, or a convention that changed how the team debugged.

The most useful thing I have built at PayPal is the tooling nobody asked for — the path the team now runs its conversion analysis through.

Four times I have taken something out of my own work and made it the team’s: a convention, an architecture pattern, a production AI pipeline, and the analysis itself.

A convention, not a ticket

Zoho · platform-wide

Problem Every service logged differently, so each incident opened with an archaeology phase before anyone could start debugging.

Decision Specify one logging convention for the distributed services rather than instrument my own service well and leave it there.

Adoption Taken up team-wide across services, then applied by default in new ones.

Result MTTR down 20% team-wide in the incident numbers we track, and the convention outlasted every project that prompted it.

Making asynchronous the default

Zoho · platform architecture

Problem Cross-service communication and webhook processing ran synchronously, coupling services together and capping throughput on the busiest paths.

Decision Introduce Apache Kafka for event-driven communication and real-time webhook processing.

Adoption Became the pattern reached for beyond the use case it was introduced for.

Result Event-driven communication is now part of how the platform is built, on a system serving millions of users against a 99.9% SLA.

From prototype to the team’s diagnostic path

PayPal · 2025–

Problem “Why did conversion dip in DE last week?” cost one to two weeks of manual BigQuery and Datadog work, and the knowledge of which query answers which symptom lived with a handful of people.

Decision Build a tiered multi-agent pipeline over typed, read-only MCP servers — cheapest deterministic check first, open-ended search only when the deterministic tiers come up empty.

Adoption Moved from prototype to the route conversion questions actually take.

Result Analysis turnaround down to a few hours, with every answer carrying the query that produced it.

Handing over the analysis, not the answer

PayPal · 3–4 engineers

Problem Funnel and conversion analysis routed through me, which made me the bottleneck and left the reasoning undocumented.

Decision Mentor through the flow itself — how the checkout data fits together, how to form and test a hypothesis — instead of handing back answers.

Adoption A weekly knowledge-share where each new technique or finding goes back to the whole team.

Result Analysis that took days takes hours, and it runs without me in the loop.

Built on my own time

Two systems where I chose every constraint

Public repositories. No product deadline behind either one — which is exactly why the design decisions are worth reading.

Personal 2026

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

payments-ledger-mcp ↗

Docker Compose · Testcontainers against real PostgreSQL · invariant contract tests through raw SQL · request and response examples in the README · architecture notes

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
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