jay@portfolio:~

whoami

GET /api/v1/content/profile
Animated illustration of Jay Dabhi working at a laptop next to a terminalapi — zsh$ npm run check✓ content valid✓ typecheck✓ tests passedGET /api/health 200$healthy

Jay Dabhi

Backend-focused Software Engineer · Node.js · NestJS · TypeScript · PostgreSQL · distributed systems

role
Software Engineer @ Kitchen 365
location
Ahmedabad, Gujarat, India
timezone
Asia/Kolkata (UTC+05:30)
status
Open to backend & platform engineering roles

Software Engineer with 3 years of experience designing, developing, and optimizing reliable and maintainable software systems.

Strong foundation in database engineering, system design, and software architecture. Experienced in backend engineering, API development, database optimization, and building scalable applications using Node.js, TypeScript, PostgreSQL, and Next.js.

experience

GET /api/v1/content/experience

  1. Software Engineer @ Kitchen 365

    – Present · 1 yr 2 mos · Ahmedabad, Gujarat

    Multi-tenant B2C SaaS eCommerce platform for US kitchen cabinet retailers, kitchen pros and drop shippers.

    • Engineering a Shopify-like multi-tenant SaaS platform on NestJS, Next.js, TypeScript and PostgreSQL that serves 100+ client storefronts from a single shared service architecture deployed as a distributed system on Kubernetes.
    • Implemented directory-based database sharding (database-per-tenant) that keeps every client's data fully isolated while routing all traffic through one codebase, removing per-client forks entirely.
    • Own versioned schema management through a self-maintained shared library of common migrations, entities and DTOs, letting tenants run concurrent schema versions with automated TypeORM rollouts and zero-downtime onboarding.
    • Designed a pluggable distributed CRM and accounting connector framework (Freshsales, QuickBooks) communicating asynchronously over Amazon SNS topics and SQS queues, where onboarding a new client is a configuration change with zero code — days of integration work down to minutes.
    • Built the master-to-tenant catalog sync pipeline that maps products, categories, attributes and inventory while preserving each tenant's customizations through selective field updates and reference tracking.
    • Engineered high-throughput catalog generation with streaming JSON writes, atomic file swaps and in-memory metadata caching, serving large multi-tenant catalogs without memory exhaustion or write race conditions.
    • Automated catalog and content onboarding with AI-powered pipelines that generate category, product and landing-page copy in each brand's voice, replacing the manual copywriting pass and sharply reducing effort for the catalog team.
    • Delivered core commerce surfaces across admin and storefront services — Redis caching, sales rules, quotes, invoices, shipments and payments (Stripe, PayPal, Clover) — plus tenant analytics aggregating revenue, leads and engagement over 100k+ orders.
    • Built the platform with strong backward compatibility and successfully migrated 23 clients off Magento onto the product, reducing server and deployment cost by 40% and improving maintainability through reusable, shared components.
    • NestJS
    • Next.js
    • TypeScript
    • PostgreSQL
    • TypeORM
    • Redis
    • Kubernetes
    • AWS SNS
    • AWS SQS
    • Stripe
    • PayPal
    • Clover
    • OpenAI API

  2. Junior Software Engineer @ Zerotime Solutions

    – · 1 yr 4 mos · Ahmedabad, Gujarat

    • Engineered secure, scalable backend systems for multiple live production products using Express.js and NestJS, contributing to architecture design, API development and performance tuning.
    • Developed an AI-powered product review generation platform using SerpAPI, OpenAI Assistants API, Supabase and Next.js, with Stripe billing for recurring subscriptions.
    • Integrated Stripe for a dynamic SaaS subscription model covering real-time upgrades, downgrades, proration, refunds and cancellations.
    • Designed a high-performance feed API for a social networking mobile app with pagination and location-based filters, keeping response times low as the user base grew.
    • Express.js
    • NestJS
    • Next.js
    • Supabase
    • OpenAI Assistants API
    • SerpAPI
    • Stripe

  3. Software Engineer Intern @ Zerotime Solutions

    – · 7 mos · Ahmedabad, Gujarat

    • Built secure CRUD APIs for Products, Orders and Users in a production e-commerce application and contributed to its microservices-based architecture.
    • Refactored cron job logic for free-tier point-expiry notifications, eliminating redundant executions and improving scheduling precision; resolved critical backend bugs that improved API response times.
    • Node.js
    • REST APIs
    • Microservices
    • Cron scheduling

systems i've built

GET /api/v1/content/systems

The work behind the bullet points: what the problem was, how it was designed, what it had to survive, and what changed because of it.

Database-per-tenant sharding for a multi-tenant SaaS

Kitchen 365

problem
100+ client storefronts needed fully isolated data, without maintaining a separate fork of the codebase for each client.
design
  • Directory-based sharding: a tenant directory resolves each request to that tenant's own database.
  • All traffic flows through one shared codebase and service architecture, deployed as a distributed system on Kubernetes.
guarded against
  • Cross-tenant data access — isolation is structural (separate databases), not a WHERE clause someone can forget.
  • Per-client drift — no forks, so every fix and feature reaches every tenant.
outcome
Per-client forks removed entirely; one platform serves 100+ storefronts.
  • NestJS
  • PostgreSQL
  • TypeScript
  • Kubernetes

Versioned schema management with zero-downtime onboarding

Kitchen 365

problem
With a database per tenant, schema changes must roll out across many databases that will not all be on the same version at the same time.
design
  • A self-maintained shared library of common migrations, entities and DTOs used by every service.
  • Tenants can run concurrent schema versions; TypeORM rollouts are automated.
guarded against
  • Services and schemas drifting apart — entities, DTOs and migrations ship together from one library.
  • Downtime during onboarding — new tenants are provisioned without interrupting existing ones.
outcome
Zero-downtime tenant onboarding with automated schema rollouts.
  • TypeORM
  • PostgreSQL
  • TypeScript

Configuration-driven CRM & accounting connector framework

Kitchen 365

problem
Every client integration with a CRM or accounting system (Freshsales, QuickBooks) took days of custom work.
design
  • A pluggable, distributed connector framework communicating asynchronously over Amazon SNS topics and SQS queues.
  • Onboarding a new client is a configuration change — no code.
guarded against
  • Coupling the storefront to third-party availability — integrations run asynchronously over queues instead of in the request path.
outcome
Client integration time cut from days to minutes.
  • AWS SNS
  • AWS SQS
  • Node.js
  • Freshsales
  • QuickBooks

Master-to-tenant catalog sync

Kitchen 365

problem
A master catalog must flow to every tenant, but tenants customize their copies — a naive sync would overwrite their changes.
design
  • Maps products, categories, attributes and inventory from master to each tenant.
  • Selective field updates plus reference tracking decide what may be overwritten.
guarded against
  • Clobbering tenant customizations on every sync.
outcome
Tenants receive master catalog updates while keeping their own customizations.
  • NestJS
  • PostgreSQL
  • TypeScript

High-throughput catalog generation

Kitchen 365

problem
Large multi-tenant catalogs had to be generated and served without running out of memory or serving half-written files.
design
  • Streaming JSON writes keep memory flat regardless of catalog size.
  • Atomic file swaps: write to a temporary file, then rename over the live one.
  • In-memory metadata caching avoids re-reading large files.
guarded against
  • Memory exhaustion on large catalogs.
  • Write race conditions — readers see the old file or the new one, never a partial write.
outcome
Large multi-tenant catalogs served without memory exhaustion or write races. (This site's message store uses the same temp-file + atomic-rename technique.)
  • Node.js streams
  • TypeScript

Migrating 23 clients off Magento

Kitchen 365

problem
Clients running on Magento had to move onto the new platform without breaking what they relied on.
design
  • Built the platform with strong backward compatibility.
  • Reusable, shared components instead of per-client implementations.
guarded against
  • Breaking existing client behaviour during migration.
outcome
23 clients migrated; server and deployment cost reduced by 40%, with better maintainability.
  • NestJS
  • Next.js
  • PostgreSQL

SaaS subscription billing with Stripe

Zerotime Solutions

problem
An AI-powered product review generation platform (SerpAPI, OpenAI Assistants API, Supabase, Next.js) needed a dynamic recurring-subscription model.
design
  • Stripe integration covering real-time upgrades and downgrades with proration.
  • Refunds and cancellations handled as first-class flows.
guarded against
  • Incorrect charges on mid-cycle plan changes — handled through proration.
outcome
A complete subscription lifecycle: upgrade, downgrade, proration, refund and cancellation.
  • Stripe
  • Next.js
  • Supabase
  • OpenAI Assistants API
  • SerpAPI

Feed API for a social networking app

Zerotime Solutions

problem
A mobile app's feed needed to stay fast as its user base grew.
design
  • Paginated feed API with location-based filters.
guarded against
  • Unbounded result sets — every response is paginated.
outcome
Response times kept low as the user base grew.
  • Node.js
  • Express.js

how i review a backend change

I look at every change through the same questions. Most production incidents are an answer to one of these that nobody asked.

  1. InputWhat is the largest, smallest, empty, malformed, duplicated or unicode-tricky input — and does validation happen before anything expensive?
  2. ConcurrencyWhat happens if this runs twice at the same time, or the same request is retried? Idempotency, locking and atomic writes.
  3. IsolationIn a multi-tenant system, is there any path where one tenant's request can read or write another tenant's data?
  4. FailureWhat if a dependency is slow, down, or returns garbage? Timeouts, retries with limits, and a defined degraded mode.
  5. Data & schemaIs the migration backward compatible with the code still running, and can it be rolled back?
  6. SecurityWho can call this, how often, and what can they learn from its errors?
  7. LimitsWhat bounds memory, disk, queue depth and payload size — and what happens at the bound?
  8. ObservabilityIf this fails at 3am, can I find the exact request in the logs without leaking user data into them?

skills

GET /api/v1/content/skills
backend
  • Node.js
  • NestJS
  • Express.js
  • REST APIs
  • Swagger
  • ABAC
  • Supabase
database
  • PostgreSQL
  • MySQL
  • MongoDB
  • Redis
  • GraphQL
  • TypeORM
architecture
  • System design
  • Multi-tenancy
  • Database sharding
  • Schema versioning & migrations
  • Event-driven (SNS/SQS)
  • Microservices
  • Caching
cloud & devops
  • AWS EKS
  • AWS SNS
  • AWS SQS
  • EventBridge
  • CloudWatch
  • Lambda
  • RDS
  • EC2
  • Kubernetes
  • Docker
  • Git
  • Bitbucket
payments
  • Stripe
  • PayPal
  • Clover
frontend
  • Next.js
  • React.js
  • TypeScript
ai / ml
  • OpenAI API
  • RAG
  • Vector Search

achievements

GET /api/v1/content/achievements

education

GET /api/v1/content/education

contact

POST /api/v1/contact

Hiring for backend or platform work, or want to talk system design? Send a message — it goes through the same validation, abuse controls and delivery pipeline described on /system.

Delivered privately on the server side; your IP address is never stored in plain text. Messages sent less than 3s after the page loads are treated as automated.

Prefer email? jaydabhi112@gmail.com