liju thomas

sre at aion.xyz · bangalore, 2025–ongoing

• -platform engineering: kubernetes on eks provisioned with terraform, autoscaling with karpenter, and gitops with argocd + helm
• -sre, covering observability, incident response, capacity planning, and reliability engineering
• -operating the full o11y stack: prometheus, loki in distributed mode, and grafana
• -architected the cluster, networking, and observability (tempo tracing, oidc) for project meridian, aion's terraform-managed eks platform built for rezolve
• -added canary deployments via argo rollouts on the helm chart, flexible enough to run real traffic shaping through nginx ingress or plain pod-count shaping through kube-proxy alone, with prometheus-backed analysistemplates for automated analysis runs
• -built the go agent installed on every aion node, pulling user-submitted tasks through systemd/k8s task drivers, with sqlite+wal for local state, full audit logging, and m2m bootstrap auth; also built the grpc backend services behind it alone, on postgres, exposed through grpc-gateway
• -traced gpu vm spin-up time end to end, through api timestamps, k8s events, virt-launcher/qemu logs, and cloud-init blame timing, then found the chokepoints and reworked the flow for a 10% gain
• -added a cache pvc for the notebook addon, using cdi smart-clone on longhorn and uv for fast installs, cutting its spin-up time
• -built the marimo notebook addon for aion's gpu vms, plus port forwarding for them, using nginx for port exposure and network policies for isolation
• -building microservice systems in go, working on the kong api gateway, event-driven services, and grpc
• -built aion-cli alone in go, with cobra and a bubbletea/lipgloss tui, covering ~90% of aion's core apis
• -worked on aion's console (next.js): gpu/k8s provisioning flows, rjsf-driven config forms, zustand + indexeddb state, shipped across many releases

intern at brototype · kochi, 2024–2025

• -built zenx, a competitive coding platform, from scratch: go, typescript, react, grpc, nats, docker sandboxing, postgres, mongodb, redis, prometheus, grafana, aws, gcp, kubernetes

go, typescript, react, gRPC, nats, docker sandbox, postgres, mongodb, redis, prometheus, grafana, aws, gcp, kubernetes

• -api gateway: go + gin, the single rest entrypoint proxying grpc to every service, with prometheus metrics, ip-based rate limiting, and a ristretto cache used as a jwt blacklist store
• -auth & user service: grpc, postgres via gorm, redis session cache, jwt issuance and rotation, totp-based 2fa, role-based admin controls
• -problem service: mongodb for problems and test cases, redis cache, nats for async solution validation, redisboard for problem-level leaderboards
• -code execution engine: docker-sandboxed judging for python, javascript, c++, and go, dispatched through a nats-driven worker pool
• -challenge service: local in-process state for live battles, redis-backed shared state, leaderboard backed via redisboard (sorted linkedlists), reads fall back to mongo once a challenge's been archived, graceful shutdown flushes completed challenges to mongo for permanent history and snapshots current matches in redis to .rdb
• -frontend: react 19, vite, typescript, shadcn/ui, a real-time battle arena over websockets using a dispatch pattern
• -commonproto: a global proto store, the single source of truth for every service's grpc contracts
• -infra: terraform for cloud bootstrap and core (vpc, ecr, route53, eks), k3s + kustomize on-prem, argocd gitops, prometheus/grafana monitoring

go, redis

• -atomic, pipelined score updates and o(log n) top-k / rank queries over redis sorted sets
• -namespaced per leaderboard, built to scale to ~1m users and 200 entities
• -the leaderboard engine behind zenx's problem and challenge services

go, gin, mysql, gorm, grpc, docker, kubernetes

• -started as a go + gin monolith: gorm/mysql, google oauth, jwt sessions, stripe + razorpay payments, cloudinary uploads, smtp notifications
• -re-architected into grpc microservices (api gateway, user, restaurant + product, order + cart, admin auth), with a centralized proto repo as the shared contract source

python, django, postgres, redis, scylladb

• -postgres for entity data: users, organizations, namespaces, url metadata
• -redis as a cache layer in front of the hot paths
• -scylladb holds the short-url lookup table itself, since resolving a short code is the highest-read path by far
• -partitioned by (namespace, shortcode), a single-partition-key lookup with predictable routing per redirect, plus a separate click-analytics table clustered by date, since scylla's wide-column model is well suited to high-volume, append-heavy event workloads

go, gin, react, typescript, postgres, elasticsearch, mongodb

• -ingestion path: a batcher flushing on size or a timer, a worker pool with retries and backoff writing to postgres via copy, object pools and gc tuning to cut allocation overhead, and a mongo dead-letter queue for anything invalid or timed out instead of dropping it
• -a separate query service indexes postgres into elasticsearch, gated behind a real cluster health check so it backs off instead of indexing into a degraded cluster, with manual dlq reprocessing back into postgres
• -frontend: react + typescript, with a near-live view of the log stream drawn straight onto a canvas over a websocket feed, color-coded by level
• -load-tested on a resource-capped setup matching its own compose limits: scaling to ~50-55k logs/sec at batch size 200, zero failures