Ashish Chandrashekar
Backend & distributed systems SWE III @ CVS Health New York

Most of the work is in what breaks.

I'm Ashish. I build backend systems where the happy path is maybe 20% of the problem — the rest is retries, partial failures, and the thing nobody thought to check. Six-plus years across real-time control systems, card rewards platforms and healthcare data infrastructure.

Inspect the systems Email Résumé (PDF) LinkedIn
01

Systems I've been responsible for

toggle each one to see what breaks

Every one of these has a nominal view and a failure view. The nominal view is the architecture. The failure view is what I actually spent my time on.

CVS Health Software Engineer III 11/2025 — present

Agents that migrate pipelines nobody fully documented

Legacy SAS and Teradata pipelines, moving to BigQuery. The translation itself is tedious but tractable; the hard part is that an LLM will hand you a confident answer whether or not it's the right one, and the pipelines have behavior that isn't written down anywhere. So the interesting design question isn't "can an agent write the SQL" — it's "what does the system do when the agent is wrong."

3 known failure modes
  1. 1SAS / Teradatalegacy source
  2. 1Planner agentLangGraph
  3. 2Migration workstreams ×5+concurrent
  4. 3Airflow / Dataprocorchestration
  5. BigQuerytarget
  1. 01

    A plan that reads correctly and isn't. Model output is fluent by default, so fluency tells you nothing — a single long generation gives you one place to be wrong and no way to localize it.

    Built the orchestration as discrete, individually checkable steps rather than one monolithic generation, so a bad step surfaces at the step instead of at the end of a three-week migration.

  2. 02

    One workstream taking the others down. Five-plus migrations run at once; without isolation, one bad translation stalls a team that has nothing to do with it.

    Designed the backend services (Python, FastAPI) for modularity and fault tolerance so workstreams fail independently — a stall is contained to one team, not the program.

  3. 03

    Long transformations dying halfway and leaving partial state — the failure that's worse than no run at all, because now the warehouse looks fine and isn't.

    Everything executes through Airflow and Dataproc, so retry and re-run are the ordinary path rather than a manual recovery someone performs from memory.

3 months → <3 weeksper migration project
5+concurrent workstreams
PythonFastAPILangGraph AirflowDataprocBigQueryGCP
American Express Software Engineer II 10/2023 — 06/2025

A rewards engine several teams change at the same time

Rewards for Clear, Uber, Dell, Adobe and others, all running on one platform, all with different threshold and accrual rules, all being modified concurrently by teams who don't sit together. The money is real and the ledger is downstream, which means the expensive bugs aren't crashes — they're the events that got processed slightly too early and looked fine.

3 known failure modes
  1. 1Card productsClear · Uber · Dell · Adobe …
  2. 1Configurable rules engineJava · Python
  3. Threshold & accrualreward logic
  4. 2Event streamtagged / gated
  5. 3Downstream consumersKubernetes
  1. 01

    Every new card product becoming a new code path. The failure here is slow: nothing crashes, the platform just gets harder to change every quarter until nobody wants to touch it.

    Redesigned it around a configuration-driven engine instead of per-product branches, and wrote the code guidelines to go with it — because the engine was going to outlive my time on the team. Later feature development ran about 40% faster.

  2. 02

    A consumer acting on an event whose dependencies haven't landed yet. This is my favorite class of bug: no exception, no alert, and it surfaces three services away looking exactly like data corruption.

    Built an event tagging system that automatically flags events and holds them until their dependencies clear, so the ordering assumption is enforced by the platform rather than remembered by each consumer. Incident bug reports dropped about 20%.

  3. 03

    A production issue you can't reproduce. Every hour spent trying to recreate state by hand is an hour the bug is still live.

    Designed an event replay mechanism inside a custom Kubernetes environment — cut the manual operational effort roughly in half for that class of issue.

~40%faster later development
~20%fewer incident bug reports
~50%less manual ops effort
JavaPythonKafkaKubernetes PostgreSQLEvent-driven
FTC Solar Software Engineer → Software Engineer II 05/2019 — 08/2022

Software that moves steel in a field

Control and telemetry for 100+ networked nodes on solar tracker installations, from the SCADA layer up to the web UI. This is the system that shaped how I think about everything since: a bad deploy here doesn't render wrong, it points hardware the wrong way in weather. There was no spec to inherit — most of the job was working out what the requirements were before building against them.

3 known failure modes
  1. 1100+ tracker nodessensors · Modbus
  2. 1MQTT command bussimultaneous
  3. 3Services (SOA)Python · FastAPI · C++
  4. Nginx / Gunicorn150+ endpoints
  5. 2SCADA + React UIreal-time
  1. 01

    Commands to many nodes at once colliding, or arriving in an order nobody intended. On a screen that's a glitch; on a tracker array it's physical.

    Executed a command processing strategy for simultaneous data across nodes over MQTT, so concurrent instructions have defined behavior instead of emergent behavior.

  2. 02

    Dashboards going stale because every reading funnels through the backend. An operator trusting a number that's forty seconds old is worse than showing them nothing.

    Enabled a direct node-to-UI channel that bypasses the backend for real-time data, so what the operator sees is what the hardware is doing now.

  3. 03

    A monolith where one bad deploy costs you control of the whole site — and a codebase where you can't test a change in isolation because nothing is isolated.

    Drove the migration to a service-based architecture with new REST APIs and rigorous unit testing behind them, then took deployment on Kubernetes end to end — monitoring and documentation included, because at 3am the documentation is the system.

150+endpoints built
100+network nodes served
Presidential Awardnomination, FTC Solar
PythonC++FastAPINode.js ReactMQTTModbusKubernetesNginx
02

How I work

five things, plainly
  1. 01

    The happy path is the easy part.

    What happens when this node dies mid-write? When the upstream sends the same event twice? When a dependency hasn't landed yet? Those answers shape the design, so I'd rather have them on day one than discover them in an incident channel. The Amex event tagging system exists because of that question, and it's the change I'm proudest of.

  2. 02

    Right the first time is the cheaper option.

    Rework costs more than it looks like on the ticket — it costs the three teams who already built against the thing you're changing. I'd rather spend the extra day on the interface, the guidelines and the tests than spend a quarter unwinding a decision. This isn't perfectionism; it's arithmetic.

  3. 03

    Ambiguity is the actual job.

    "Migrate the legacy pipelines" and "make the trackers controllable" are directions, not requirements. The first pass is always working out what's really being asked, listing what nobody knows yet, and finding which of those unknowns is going to hurt. I'd rather name the unknown early and be wrong about it than pretend the spec is complete. That's ended up being how I get used: on my last two teams I'm usually the one the badly-scoped problem lands with. Not because I'm the strongest engineer in the room — because I'm comfortable starting before the requirements exist, and I don't put it down until the thing actually works.

  4. 04

    I don't hand things off at 80%.

    End-to-end means through deployment, monitoring, and the documentation the on-call person needs at 3am. The last 20% is where a system either becomes something a team can operate or becomes something only I can operate — and the second one isn't finished.

  5. 05

    None of the above was done alone.

    Every system on this page had product, design and other engineers attached to it, and the designs got better for it. The part of the job I like most is arguing about an approach with someone who sees the problem differently and landing somewhere neither of us started.

03

Working with AI

two different problems

Half of my current job is building systems that use models. The other half is using models to do my own job faster. They fail in completely different ways, so I treat them as separate problems.

I treat model output as untrusted input.

the only rule that has held up across both
Building systems that use models

At CVS that's agent orchestration in LangGraph — planning and translation agents that take legacy SAS and Teradata pipelines into BigQuery, across 5+ concurrent migration workstreams. At Amex I proposed and architected a RAG assistant over GitHub and Confluence, so the knowledge people kept re-asking in chat lived somewhere you could actually query.

The engineering in both is the same, and almost none of it is prompting. A fluent answer and a correct answer look identical, so the system has to assume every step is suspect: small checkable steps instead of one long generation, isolation so a bad step can't take a neighboring workstream down with it, and something a human can diff before it reaches production. The model is a component with a known failure mode — you design around it the same way you design around a flaky network.

Using AI to do the work

I use AI-assisted development every day — exploring code I didn't write, first drafts, the boring 80% of a migration script, test scaffolding. It's genuinely changed how fast I can get to a working version of something.

What I don't do is ship code I couldn't have written myself and can't debug at 3am. The dangerous output isn't the kind that breaks — it's the kind that runs, passes the obvious test, and quietly encodes an assumption nobody checked. That's the same bug class I spend my time on everywhere else, which is why I read all of it.

The net effect is that the ratio shifted. Less time typing, more time on the parts that were always the actual job: what the interfaces should be, what happens when this fails, and whether the thing we're building is the thing that was needed.

04

Stack

things I've shipped with, not things I've read about

Backend

  • Java
  • Python
  • Go
  • C++
  • FastAPI
  • gRPC
  • REST
  • Microservices

Data & events

  • Kafka
  • PostgreSQL
  • Redis
  • OpenSearch
  • Airflow
  • BigQuery
  • DynamoDB
  • Pinecone
  • MQTT

AI systems

  • LangGraph
  • Multi-agent orchestration
  • RAG
  • Vertex AI
  • Vector DBs

Platform

  • Kubernetes
  • Docker
  • AWS
  • GCP
  • API Gateway
  • CI/CD
  • Splunk
  • Kibana
  • Nginx

Frontend

  • TypeScript
  • React
  • Next.js
  • Node.js
  • WebSockets
  • Jest
  • Playwright
05

Off hours

same discipline, higher stakes

I climb, and I race motorcycles and cars. As far as I'm concerned they're the same hobby: systems where the failure modes aren't abstract. On a wall you read the sequence, work out where you come off and what happens when you do, and then commit to a move you can't half-do. On a track you're managing tires, brakes and your own attention across a stint, and being 5% too optimistic into a corner has a cost you can't refactor. Both reward the same thing my work does — think hard about what breaks, then commit completely anyway.

Ashish mid-move on a steep overhang at an indoor bouldering gym, body horizontal, reaching for the next hold
Read the holds, rehearse the fall, then commit.
Ashish leaned into a corner on track aboard a green Kawasaki Ninja
No redo. No rollback.
06

Education

M.S., Artificial Intelligence

Arizona State University
08/2022 — 12/2023

B.Tech, Computer Science & Engineering

National Institute of Technology Karnataka, Surathkal
07/2015 — 05/2019

Admission runs through JEE Main. ≈1.3 million candidates sat it the year I applied; NITK's CSE seats close around all-India rank 3,400. That's roughly the top 0.3%. Stating it as a number because the school's name doesn't travel outside India.

07

If you're building something where the failure case matters, I'd like to hear about it.

Looking for software engineering roles on systems big enough that the failure cases actually matter — distributed backend, platform or infrastructure. Fastest way to reach me is email; I answer everything that isn't a template.

Ashish Chandrashekar, smiling, with the Manhattan waterfront behind him
Email oneashishc@gmail.com LinkedIn /in/ashishchandrashekar GitHub @ashish47 Résumé PDF ↓