Skip to content
jalay_movaliya

Jalay Movaliya

Software engineer · Bangalore, India

Software engineer.Builder of systems.Solver of problems.

I build backend systems, APIs and the products on top of them — most recently a contest judge that handles 3,500+ submissions an hour and a Discord bot that ran across 580,000+ servers. I like finding the bottleneck, understanding why it's there, and making the system faster and more predictable.

Selected workResume (opens in a new tab)
~/jalay — zsh-ishsimulated · type “help”

jalay@portfolio ~ $ whoami

name
Jalay Movaliya
role
software engineer — backend, systems, APIs
now
software product developer intern @ Eli Lilly and Company
based
Bangalore, India
study
B.Tech Computer Engineering, CHARUSAT · 9.64

Command shortcuts

Currently Software Product Developer Intern at Eli Lilly and Company, Bangalore, India.

01~/work

Selected work

A contest platform used by 200+ students, a bot that ran across hundreds of thousands of servers, and product work at Genuin. For each: what it does, what I built, and the decisions that mattered.

A

Personal projectCompetitive programming platform

codepie.app (opens in a new tab)

CodePie

A university-scale competitive programming platform: students submit code, a judge cluster runs it in isolation, verdicts come back in real time and the contest leaderboard keeps up.

The problem

Contests are bursty. Hundreds of students submit within the same window, each expecting a verdict in seconds, while the leaderboard has to stay correct without the database becoming the bottleneck.

active students
200+
submissions / hour, stable uptime
3,500+
submissions / min in load tests, no degradation
1,000
fig. 1 — submission lifecycle

Request pathon submit

  1. client

    Code editor

    React · Monaco

  2. service

    Submission API

    Go · chi → 202 Accepted

  3. external

    Judge0 cluster

    self-hosted · all hidden tests in one run

Judge0 calls back with a signed token naming the submission

Result pathper callback

  1. callback

    Verify callback

    token checked, then graded

  2. store

    Persist result

    pgx · sqlc → PostgreSQL

  3. client

    Live verdict

    Server-Sent Events → browser

only the submission is written — no scores or ranks stored

Ranking pathcomputed on read

  1. client

    Leaderboard request

    paginated, team aware

  2. store

    One SQL query

    best score per problem → rank() window

  3. client

    Standings

    always current, nothing to sync

Drawn from the current Go backend. Ordering inside each lane is simplified, and supporting pieces (auth, nginx, monitoring) are not drawn.

What I built

  1. 01Built and deployed the platform, used by 200+ active students.
  2. 02Moved the backend from Node.js, Express and Prisma to Go (chi, pgx, sqlc) on a normalized PostgreSQL schema with hand-written migrations.
  3. 03Runs untrusted code on a self-hosted Judge0 cluster, judging each submission in a single run with all hidden tests concatenated instead of one run per test.
  4. 04Judge0 reports back through a callback carrying a signed token, so verdicts can't be forged; students get them live over Server-Sent Events.
  5. 05Leaderboards went from recalculation on every callback, to scheduled batches, to a single SQL query over submissions — no stored scores to keep in sync.

Stack

  • Go
  • chi
  • sqlc
  • PostgreSQL
  • Judge0
  • SSE
  • React
  • TypeScript
B

Personal projectDistributed Discord bot · 2021 — 2022

Soul Music

A music bot for Discord that grew large enough to need the same things any distributed service needs: horizontal scale, careful use of rate limits, and audio offloaded to dedicated nodes.

Discord servers
580,000+
daily users
10,000+

Usage figures from the Discord Developer Portal.

  1. 01Split the bot into shards spread across clustered processes, so each process holds a bounded set of gateway connections and stays inside Discord's rate limits.
  2. 02Moved audio off the bot entirely: playback runs on Lavalink nodes, driven from the bot through Shoukaku.
  • Node.js
  • Discord.js
  • Shoukaku
  • Lavalink
fig. 2 — topologyschematic, not to scale
guilds (servers) shards in clustered processes Lavalink nodes via Shoukaku
C

Professional work · GenuinFull-stack product engineering

Multi-agent conversations

Contributed to a multi-agent conversational platform and an automated brand onboarding engine, mostly on the frontend, with backend work where it mattered.

autologin latency, Aerospike cache
~1 s → 50 ms
brand onboarding time
30 min → <1 min
  1. 01Built the frontend for multi-agent conversations: agent interaction workflows, message rendering, and chat editing with version traversal.
  2. 02Implemented the frontend for automated brand onboarding.
  3. 03Integrated Aerospike caching into the authentication flow.
  4. 04Debugged backend services and built CRUD APIs.
  • Next.js
  • React
  • Zustand
  • Go
  • Node.js
  • PostgreSQL
  • MongoDB
  • Aerospike
fig. 3 — interaction patternillustrative mockup

you · edited

Draft two launch posts for the spring collection, under 80 words each, one playful and one minimal.
3 / 3

agent · planner

Splitting this into two drafts and handing tone to the writer agent.

agent · writer

A representative mockup of patterns I built — not a product screenshot. Use the arrows to step through the edited message's versions.

Earlier, smaller things

  • PrepArc

    AI interview and hiring platform: generated quizzes, mock interviews with feedback, resume ATS scoring. Team project — I led the backend.

    NestJS · Prisma · PostgreSQL · Socket.IO

    2024 — 2025

  • SpouBuzz

    Live cricket scoring site for the university sports fest, with real-time score updates.

    Node.js · Express · Socket.IO · PostgreSQL

    2023 — 2024source (opens in a new tab)

  • UniVerse Bot

    Telegram bot that gives students quick access to course materials.

    Node.js · Telegraf

    2023source (opens in a new tab)

02~/experience

Where I've worked

Three internships — backend services, internal platforms, developer tooling and the product surfaces on top of them.

  1. —

    Eli Lilly and Company

    Software Product Developer Intern · Bangalore, India

    • Built RelayHub Control Centre, a knowledge base platform with FAQ versioning, approval queues and audit logs.
    • Shipped text-to-speech and speech-to-text for Chat-in-a-Box.
    • Built a Go MCP server, integrated with AWS S3, that gives the Eliza AI agent native image generation.
    • DevOps subject-matter expert for Inkstone: CI/CD, infrastructure and deployment practices.

    Technologies: Python · FastAPI · PostgreSQL · Next.js · Go · AWS S3

  2. Genuin Codebase LLP

    Software Development Engineer Intern · Ahmedabad, India

    • Built frontend experiences for a multi-agent conversational platform.
    • Developed brand onboarding interfaces and contributed to backend APIs.
    • Cut autologin latency from ~1 s to 50 ms by adding Aerospike caching to the authentication flow.

    Technologies: Go · Node.js · PostgreSQL · MongoDB · Aerospike · React · Next.js · Zustand

  3. —

    Neev Technologies

    Software Development Engineer Intern · Remote

    • Integrated Plaid for automated KYC and Mercury for withdrawal automation.
    • Improved the admin dashboards and mobile app.
    • Debugged backend logic and fixed API behaviour and navigation issues.

    Technologies: Node.js · PostgreSQL · React · React Native

03~/about

Things I care about when building software.

Habits more than rules — the ones I keep coming back to, and where they showed up in real work.

  1. 01

    Performance is a product feature.

    Users feel latency before they read a word on the page. A login that takes 50 ms instead of a second is a better product, even if nothing on screen changed.

    Aerospike in the auth path
  2. 02

    Measure before optimizing.

    Profile, load-test, read the query plan. Capacity should be a number you measured, not a feeling — CodePie was pushed to 1,000 submissions a minute to find out.

    CodePie load testing
  3. 03

    Find the bottleneck before adding infrastructure.

    CodePie's database load came from recalculating the leaderboard on every judge callback. The fix was to stop doing that work per event, not to add hardware.

    How the leaderboard evolved
  4. 04

    Keep data access predictable.

    The work a database does should be the work you planned for. CodePie's standings are one indexed query over submissions — no derived scores stored, nothing to drift out of sync.

    Deriving the leaderboard
  5. 05

    Design for failure, not just the happy path.

    Decide what happens when a dependency is slow, a callback never arrives or a deploy goes half-way — before it happens in production.

  6. 06

    Prefer simple systems with clear failure modes.

    A query you can reason about beats a clever pipeline nobody can debug at 2 a.m. Replacing CodePie's leaderboard cron with SQL removed a moving part entirely.

Toolbox

Backend
Go, Node.js, Python, FastAPI, Express.js
Data & storage
PostgreSQL, Redis, MongoDB, Aerospike
Distributed systems
Queues, Caching, WebSockets, Rate limiting
Frontend
React, Next.js, Tailwind CSS
Infra & tooling
Docker, AWS S3, Git, Jest
Also used in projects
sqlc, Prisma, Socket.IO, SSE, Judge0, Discord.js, Shoukaku, Lavalink, Zustand, React Native

Problem solving

  • LeetCode Knight

    Reached a 1980 contest rating, placing in the top 3% globally.

    profile (opens in a new tab)

  • 7th of 1,000+

    Coders' Arcade competitive programming contest.

  • Top 7 — Odoo × IIT Gandhinagar Hackathon

    Led development of Heal.AI, a multilingual healthcare assistant.

    post (opens in a new tab)

  • Odoo × CHARUSAT Hackathon 2025

    Led logistics and technical setup, including QR-based registration and check-in.

Education

Charotar University of Science and Technology (CHARUSAT)

B.Tech, Computer Engineering

CGPA 9.642022 — 2026

04~/contact

Have an interesting problem to solve?

I'm always interested in discussing engineering challenges, useful products, and interesting systems. Email is the fastest way to reach me.

jalaym825@gmail.com
Write an email
Portrait of Jalay Movaliya
fig. 4 — the authorjalay