Senior backend engineer with 6+ years of backend SaaS experience (OTT, healthcare, logistics, fintech), specialized in high-concurrency caching, distributed locking, multi-tenant architecture, and RESTful API design. I also build AI applications — LLM agents with RAG, tool-use, and long-term memory using Python/FastAPI and the Claude/OpenAI APIs — and bring AI-assisted development across design, implementation, testing, and documentation.

• 🤖 Building LLM agents (tool-use + long-term memory), RAG, and structured memory with Python/FastAPI
• ⚡ Strong backend foundation: caching, distributed locking, and API design under load (Rails 7/8)
• ✍️ Writing a deep-dive series on Rails performance — Lessons from Production
• 🧰 Daily driver of Claude Code / AI-assisted development
• 🌏 Open to AI Engineer / backend roles, incl. international remote

An AI journal for energy, wins, and gratitude: write the day once, and it becomes a memory that answers questions about your own record months later — naming the days each answer draws on. Built on a three-layer memory architecture — structured Postgres journal + pgvector semantic recall over atomic facts + an LLM-condensed rolling profile — so the record grows indefinitely while every prompt stays bounded. The read path is write-free by construction: asking questions never mutates memory. Python/FastAPI, Claude/OpenAI, React (Vite) with a Recharts energy chart, Firebase auth, deployed on GCP Cloud Run + Cloud SQL behind a Firebase Hosting custom domain, CI/CD with Workload Identity Federation. 🔗 Live app · Overview

Creators run limited-time, limited-quantity drops; buyers get a countdown, live stock, and one-tap checkout. Underneath: row-level multi-tenancy (acts_as_tenant) with two independent tenant-resolution paths, pessimistic-lock oversell protection proven by multi-threaded race tests, an AASM order state machine with full rollback on payment failure, and signature-verified Stripe & ECPay webhooks. Full-text search via pg_search trigram, CI (RuboCop / RSpec / Brakeman / gitleaks), and observability with Scout APM + Sentry + Lograge. 🔗 Live overview

A caching gateway that absorbs a 1,000:1 supply-demand gap — serving 1M+ daily requests against an upstream capped at 1,000 calls/day — without sacrificing data freshness or breaking the upstream contract. A study in high-concurrency architecture and engineering quality (single-flight Redis locks, atomic quota guards, an anti-corruption layer, 100% test coverage). 🔗 Live overview

A repeatable health audit for legacy Rails codebases. It orchestrates the canonical tools (Brakeman, bundler-audit, RubyCritic, RuboCop, license_finder, …) and adds the judgment layer on top: ranks findings by business impact, runs runtime data-correctness checks (active_record_doctor, lol_dba) that static bundles skip, and turns the raw output into a prioritized action plan. Packaged as a Claude Code skill, with zero footprint on the target project.

Rails Performance: Lessons from Production — a deep-dive series that diagnoses real performance incidents one layer at a time (SQL → caching → background work → infrastructure), all on a single running example.

📍 Read it on dev.to/danewu and Medium.

Start here

• Diagnosing a slow Rails page, layer by layer — locating slowness by request layer: N+1 vs. a single slow query, and how dev tooling and a production APM fit together.

Database layer

• From 8s to 1s: Truly Understanding Rails N+1 by Opening Up ActiveRecord — a four-layer mental model of ActiveRecord (Ruby → SQL → DB → memory) that explains N+1, broken preloads, and row explosion.
• A 1000x Speedup From One Index — and Why It Sometimes Does Nothing — how indexes actually work (B-tree, leftmost prefix) and the real reasons one you added still won't kick in.
• You Wanted a Number, but Loaded 500,000 Rows Into Memory — count vs size, exists? vs present?, SQL aggregation, and find_each: let the database do the work.
• You've Tuned the Queries and It's Still Slow — Now Change the Data Model — denormalization (counter_cache, redundant hot values, materialized views), its consistency cost, and where data-model changes sit in the optimization order.

Caching

• The Fastest Query Is the One You Never Run: The Four Layers of Rails Caching — compute, invalidate, render, transfer — and the one idea that ties them together.
• We Added a Cache; Three Days Later It Took the Database Down at Peak — four production caching traps: stampede, treating cache as source of truth, unbounded keys, and caching failures.

Background work & the application layer

• One Notification Email Made Our Checkout API 3 Seconds Slower — moving slow work to background jobs: idempotency, passing ids vs. objects (GlobalID), queue priorities, retries.
• Your SQL Is Fast but the API Is Slow: It's the Ruby Layer — serialization, object allocation / GC pressure, and the memoization gotchas.

Infrastructure

• The Code Is Fine, but Requests Queue Until They Time Out: Puma, Pools, CDN — Puma workers × threads, aligning the connection pool, the GVL and IO, and offloading static assets to a CDN.

AI / LLM · Python · FastAPI · LangChain · LangGraph (agent orchestration) · RAG · pgvector (vector search) · Claude & OpenAI APIs · LangSmith · Pytest · uv · Claude Code

Backend · Ruby on Rails 7/8 · RSpec (TDD) · Sidekiq · RESTful API · JWT · Devise · Pundit · ActionCable · acts_as_tenant · AASM

Frontend · React (Vite) · Recharts · Hotwire (Turbo/Stimulus) · Tailwind CSS · JavaScript (ES6+)

Data · PostgreSQL · pgvector · MySQL · Redis · Memcached · query tuning & index design · N+1 detection (Bullet) · row-level tenancy

Infra & DevOps · AWS (EC2, RDS, S3, SES) · GCP (Cloud Run, Cloud SQL) · Docker · GitHub Actions CI/CD · Capistrano · Puma · Nginx · Brakeman · bundler-audit · strong_migrations

Architecture · System design · distributed locks (Redis SETNX) · cache architecture (Russian Doll / fragment) · rate limiting · observability (Sentry) · payment integration (Stripe / ECPay)

LinkedIn · srichsun@gmail.com