Skip to content
OMEngineer

Om Jaiswal — Founding Backend Engineer at Ravan.AI. Engineer view.

01Production systems

Five systems in production

All five built and run at Ravan.AI.

  1. 01

    Maya

    AI SecretaryRavan.AI
    The problem

    Maya has 50+ capabilities. Registering each as its own LLM tool inflates the prompt and degrades tool selection, so the capability set couldn't grow without making the agent worse.

    What Om owned

    Architected and implemented end to end: 7 microservices across Go, gRPC, Python, FastAPI, Asynq and LangGraph, including the tool-routing layer.

    • Go
    • gRPC
    • Python
    • FastAPI
    • Asynq
    • LangGraph
    Deep dive: Routing 50+ capabilities through 2 tools
    7
    microservices
    50+
    capabilities
    reachable through 2 tools
    <500ms
    latency
    for 80% of requests
  2. 02

    Agni

    Voice AI PlatformRavan.AI
    The problem

    A live call consumes an LLM slot, a WebRTC session, a telephony channel and infrastructure capacity at once. Each saturates at a different point, so one global concurrency limit either wastes capacity or overruns a layer.

    What Om owned

    Architected and implemented the core campaign execution and concurrency-management systems, including concurrency controls across every layer.

    • Python
    • WebRTC
    • SIP
    • RTP
    • Telephony
    • Queueing
    • Schedulers
    Deep dive: Four concurrency ceilings, limited independently
    1,000+
    concurrent calls
    4
    layers of concurrency control
    model · WebRTC · telephony · infra
  3. 03

    CloserX

    Outbound Calling PlatformRavan.AI
    The problem

    The outbound calling pipeline sustained 5 concurrent calls. The limit came from synchronous execution serialising work that had no ordering requirement, not from hardware capacity.

    What Om owned

    Architected and scaled the platform, and redesigned the asynchronous calling pipeline end to end.

    • Django REST Framework
    • Python
    • RabbitMQ
    • Celery
    • Redis
    Deep dive: 5 → 300 concurrent calls
    60×
    concurrency increase
    5 → 300 concurrent calls
    50K+
    AI calls / day
  4. 04

    LiveKit Fleet

    Real-Time Media InfrastructureRavan.AI
    The problem

    Real-time voice needs media servers near the user, capacity that tracks demand, and fast removal of failed nodes — without taking on Kubernetes as a dependency.

    What Om owned

    Designed and operated fleet-based LiveKit infrastructure, including geo-routing, manual overrides, self-healing and dynamic capacity management.

    • LiveKit
    • LiveKit Agents
    • WebRTC
    • Cloud infrastructure
    Deep dive: Running a media fleet without Kubernetes
    0
    Kubernetes dependency
    fleet managed directly
  5. 05

    Shopify AI Agent & Analytics

    0 → 1 PlatformsRavan.AI
    The problem

    Merchants needed an AI agent inside Shopify, and the team had no internal view of its own data. Both were proposed rather than assigned.

    What Om owned

    Proposed, architected and built both platforms from 0 → 1. Also migrated production services from Docker-based deployment to MicroK8s.

    • Python
    • Docker
    • MicroK8s
    • Shopify
    • OpenAI API
    2
    platforms from 0 → 1
    Docker → MicroK8s
    production migration
02Deep dives

Deep dives

Problem, constraints, architecture, decisions, trade-offs, implementation, result. Select a diagram node to see what it does.

    1. Problem
    2. Constraints
    3. Architecture
    4. Decisions
    5. Trade-offs
    6. Implementation
    7. Result
    Problem

    Maya is an AI Secretary with more than 50 distinct capabilities. Registering each as its own LLM tool fails in two ways: the tool schemas consume context the conversation needs, and selection accuracy drops as the model discriminates between dozens of similar options. The capability set had to keep growing without degrading the agent.

    Constraints
    • Capability count keeps growing, so the design had to be additive.
    • Under 500ms for 80% of requests, which rules out multiple model round-trips per action.
    • Go and Python both had to be first-class, not one wrapping the other.
    • Some capabilities are slow or external and can't block the conversational path.
    Architecture

    A 7-service platform. LangGraph drives the agent loop and sees only two tools, which front a routing layer that resolves an intent to one of 50+ capabilities implemented across Go and Python services over gRPC. Work that doesn't need an inline answer goes to Asynq.

    Maya — tool routing and service topology

    The LLM's view of the system is the two nodes on the left. Everything to the right is resolved by the router, not by the model.

    ▸ Read this diagram as text
    • ClientconversationUser-facing entry point into the agent loop.
    • LangGraphagent loopDrives the agent loop. Its tool list has exactly two entries regardless of how many capabilities exist.
    • 2 LLM Toolsthe entire model-facing surfaceThe full tool surface exposed to the model. Adding a capability does not add a tool.
    • Tool Routerintent → capabilityResolves a tool call into one of 50+ concrete capabilities. This is the layer that absorbs growth in the capability set.
    • Go ServicesgRPCPart of the 7-service platform. Communicate over gRPC.
    • Python / FastAPIgRPC · HTTPPart of the 7-service platform, handling the Python-side capabilities.
    • Asynqbackground jobsTakes work off the conversational path so slow capabilities don't hold up a response.
    • Client → LangGraph
    • LangGraph → 2 LLM Tools (tool call)
    • 2 LLM Tools → Tool Router
    • Tool Router → Go Services (gRPC)
    • Tool Router → Python / FastAPI (gRPC)
    • Tool Router → Asynq (enqueue) · async
    Technical decisions

    Fixed-size tool surface

    The model's tool list is decoupled from the capability list. The model calls a stable two-tool interface; a router behind it owns the mapping. Capability count becomes a routing concern, not a prompt concern.

    gRPC between services rather than REST

    Seven services in the call path with a sub-second target. A typed contract and binary wire format cut per-hop overhead and catch integration errors at compile time across a polyglot codebase.

    Go and Python each where they fit

    Agent and ML work in Python with FastAPI and LangGraph, where the ecosystem is. Concurrency-heavy service paths in Go. gRPC keeps the boundary between them cheap.

    Asynq for non-inline work

    The latency target only holds if slow work stays off the conversational path. Asynq gives the Go side background execution, so a capability that takes seconds doesn't make the response take seconds.

    Trade-offs

    • ChoseA routing layer the model can't seeoverOne tool per capability

      Prompt size and selection accuracy stay flat as capabilities grow. Cost: routing correctness is now the team's problem and needs its own tests.

    • ChoseSeven servicesoverA single application

      Go and Python each own what they're good at, and components scale separately. Cost: more deployment surface, and a network hop where a function call would do.

    • ChoseBackground execution for slow capabilitiesoverAnswering everything inline

      The latency target is only reachable if the slow path is a separate path. Cost: some capabilities finish after the turn does, which the conversation design has to handle.

    Implementation
    • 7 microservices spanning Go and Python.
    • gRPC as the inter-service contract.
    • FastAPI on the Python services.
    • LangGraph for the agent loop.
    • Asynq for background job execution.
    • A routing layer mapping 2 exposed tools onto 50+ capabilities.
    Result
    • 50+ agent capabilities reachable through a 2-tool surface.
    • Under 500ms for 80% of requests, per the system's recorded latency figure.
    • Adding a capability is a routing change, not a change to what the model sees.
    Detail not documented yet
    • Names and responsibilities of the 7 individual servicesThe diagram currently groups them by language. Real service names would make it far more concrete.
    • The schema of the 2 exposed toolsWhat arguments does the model actually pass, and how does the router resolve them?
    • How capability resolution handles an ambiguous or unmatched intent

03Engineering universe

Engineering domains

Select a domain to see the tools used there and the systems and projects behind it.

Domain

Backend

API surfaces and service architecture. The bulk of the work.

Primitives
  • Django REST Framework
  • FastAPI
  • Go
  • Gin
  • Flask
  • gRPC
Evidence
04Projects

Projects

30+ built outside work. Systems, full-stack products, and research published in IEEE.

  • Raft Distributed Consensus Simulation

    Distributed systems

    A working Raft cluster with a live dashboard showing consensus as it happens.

    Why

    Built from scratch to understand the algorithm rather than use a library.

    Hard part

    Implementing leader election, log replication and node failure recovery correctly, then surfacing cluster state in real time without distorting the behaviour being observed.

    What Om built
    • Full simulation of the Raft consensus algorithm in Go.
    • Leader election, log replication and node failure recovery.
    • gRPC for peer-to-peer communication between nodes.
    • Gin for the HTTP surface and GORM for persistence.
    • A Next.js dashboard visualising cluster state transitions and replication events in real time.

    A working cluster whose elections, replication and recovery can be watched live.

    • Go
    • gRPC
    • Gin
    • GORM
    • Next.js
    GitHub ↗

  • Skippit

    aka Hyperlocal Freelance AppFull stack

    A real-time hyperlocal freelance marketplace — tasks, live location and geospatial matching.

    Hard part

    Serving geospatial queries and continuous live location updates over WebSockets, without query load growing faster than the user base.

    What Om built
    • Django and Django REST Framework backend with a React Native (Expo) client.
    • Real-time task marketplace built on Django Channels and WebSockets.
    • Live location tracking with geospatial queries via PostGIS.
    • Redis caching on the hot paths.
    • Deployed on a Google Cloud VM.
    • Django
    • Django REST Framework
    • Django Channels
    • React Native
    • Expo
    • WebSockets
    • Redis
    • PostGIS
    • Google Cloud VM

  • Redis Clone

    aka py-redisSystems

    A Redis-compatible key-value server in Python — RESP protocol, threaded connections, in-memory store.

    Why

    Built to understand the protocol and command model from the inside rather than treating Redis as a black box.

    Hard part

    Parsing RESP correctly and serving concurrent clients over TCP while keeping a small command surface (strings and lists) faithful to Redis semantics.

    What Om built
    • TCP server on port 6379 with one thread per client connection.
    • RESP parser for Redis Serialization Protocol requests.
    • Commands: SET, GET, DEL, LPUSH, KEYS, PING.
    • In-memory datastore with type checks (e.g. WRONGTYPE on LPUSH against a string key).
    • Simple CLI client for interactive use.

    A working Redis clone clients can talk to with RESP.

    • Python
    • TCP sockets
    • RESP
    • Threading
    GitHub ↗

  • GitHub PR Review MCP

    Tooling

    A FastMCP server that lets an LLM list, review, comment on and merge GitHub pull requests.

    Why

    Wire Claude Desktop (and other MCP clients) into a real PR review loop instead of copy-pasting diffs by hand.

    Hard part

    Exposing GitHub PR operations as MCP tools and prompts so an agent can fetch a diff, suggest review comments, push them, and merge — with auth via a GitHub token.

    What Om built
    • FastMCP server with tools: list_prs, get_diff, create_pr, review_pr, suggest_comments, push_comments, merge_pr.
    • Prompt templates for structured review comments and overall PR review.
    • GitHub REST API integration with token auth.
    • Claude Desktop config for connecting the server as an MCP tool host.
    • Python
    • FastMCP
    • MCP
    • GitHub API
    • requests
    GitHub ↗

  • Implementation of Deep Learning in Metro

    aka Metro MonitoringResearch

    Computer vision system that detects incorrect seat usage in metro carriages and raises alerts automatically.

    Why

    Reserved-seat compliance is otherwise enforced socially or not at all.

    Hard part

    No usable dataset existed. The training set was built by hand — 5,000 annotated images.

    What Om built
    • YOLO-based detection model for seat occupancy.
    • A 5,000-image annotated dataset built manually and managed in Roboflow.
    • Automated alerting when a seat is used incorrectly.

    Provisional patent filed.

    • YOLO
    • Computer Vision
    • Roboflow
    • Python

  • Traffic Prediction using V2X and Clustering

    Research

    Traffic hotspot detection from V2X vehicle data using unsupervised clustering.

    Hard part

    Identifying traffic hotspots in V2X / V2AI data without labelled ground truth, which rules out supervised approaches.

    What Om built
    • K-Means and Agglomerative Clustering applied to the V2X / V2AI dataset.
    • Traffic hotspot detection from the resulting clusters.

    Published in IEEE — document 10971508.

    • Python
    • Scikit-learn
    • K-Means
    • Agglomerative Clustering
    IEEE 10971508 ↗

  • PosterCo

    aka E-commerce SystemFull stack

    A full-stack e-commerce platform with a recommendation system.

    Hard part

    Running collaborative-filtering recommendations inside a Django request cycle fast enough to be usable — handled with Scikit-Surprise and Cython.

    What Om built
    • Django and Django Templates storefront covering product catalog, cart, coupons, order history and payments.
    • A lightweight recommendation system built with Scikit-Surprise and Cython.
    • Deployed on AWS EC2 with MySQL.
    • Django
    • Django Templates
    • Python
    • AWS EC2
    • MySQL
    • Scikit-Surprise
    • Cython

  • Librosa

    aka Library Management SystemFull stack

    A production-style library management platform that replaced a paper-based record system.

    Why

    Replaced a paper system — attendance, seat allocation and student records were kept by hand.

    What Om built
    • Django REST Framework backend with a React frontend.
    • Student tracking, attendance and seat allocation.
    • Digital records replacing the paper-based system.
    • Deployed on GCP Compute Engine with Cloud SQL.
    • Django REST Framework
    • React
    • Python
    • GCP Compute Engine
    • Cloud SQL

  • Command Store

    Tooling

    A Next.js SPA for saving, searching and organising CLI commands — local-first, with import/export.

    Why

    A personal vault for commands that are easy to forget and annoying to dig out of shell history.

    Hard part

    Keeping it useful as a daily tool: fast search, tag filters, one-click copy, and JSON backup without a backend.

    What Om built
    • Next.js + React SPA with localStorage persistence.
    • Search and tag filters across saved commands.
    • Add / edit / delete with one-click copy to clipboard.
    • Import and export commands as JSON.
    • Next.js
    • React
    • TypeScript
    • Tailwind CSS
    • localStorage
    GitHub ↗
05Stack

Stack

Grouped by what it's used for.

  • Backend7
    • Python
    • Go
    • Django
    • Django REST Framework
    • FastAPI
    • Flask
    • Gin
  • Distributed Systems & Infrastructure7
    • Redis
    • RabbitMQ
    • Celery
    • gRPC
    • WebSockets
    • Django Channels
    • Asynq
  • AI & Agent Systems8
    • LangGraph
    • LangChain
    • RAG
    • Pipecat
    • LiveKit
    • LiveKit Agents
    • OpenAI API
    • Vertex AI
  • Cloud & DevOps14
    • Docker
    • Docker Compose
    • Kubernetes
    • MicroK8s
    • AWS EC2
    • AWS RDS
    • AWS S3
    • AWS EKS
    • AWS App Runner
    • AWS Secrets Manager
    • GCP Compute Engine
    • GCP Cloud SQL
    • GCP Storage Bucket
    • GitHub Actions
  • Databases5
    • PostgreSQL
    • MySQL
    • Redis
    • PostGIS
    • GORM
  • Frontend5
    • JavaScript
    • React
    • React Native
    • Next.js
    • Django Templates
  • Machine Learning & Computer Vision5
    • YOLO
    • CNN
    • Scikit-learn
    • TensorFlow
    • PyTorch
06Experience

Experience

07Contact

Contact

Happy to go deeper on any of these systems.

work.omjaiswal@gmail.comResumeLinkedIn ↗GitHub ↗Upwork ↗
New Delhi, India · Press L to switch lenses.