A sub-universe of this portfolio: the career read as a stack, interactive models of the concepts that matter, and simulated live-production scenarios.
Monolith to microservices: reference patterns
These are generic reference patterns, the shapes this kind of modernization usually takes. They are not diagrams of any real system, and every number in the simulators is invented for teaching.
Reference pattern 1: modernizing a coupled enterprise application
A monolith shares one database and makes blocking calls between its parts, so a slow report, a long onboarding step or one noisy tenant slows everyone. The usual target is a small set of domain services behind a gateway, with events at the boundaries and a cache where reads dominate.
Legacy monolith state
One deployable unit. Every feature shares one database and one connection pool. Calls between modules are synchronous, so a slow step blocks the request that triggered it. Onboarding a new client means a long, manual, tightly coupled setup that touches the whole application.
Solid line: a blocking call. Dashed line: an asynchronous event. Dotted line: an automated release.
Target microservices state
Domain services (identity, onboarding, reporting) own their data and scale independently. A gateway fronts them, long work moves behind asynchronous events, a cache absorbs repeated reads, and onboarding becomes an automated, repeatable pipeline.
Solid line: a blocking call. Dashed line: an asynchronous event. Dotted line: an automated release.
What gains come from which part
−30% backend response time(reported on the experience page) In a pattern like this, response time usually falls for three reasons: reads move to a cache instead of the shared database, slow work leaves the request path behind an event, and each service scales on its own instead of with the whole application. Parts involved: API gateway, Read cache, Reporting service, Event bus.
−20% client onboarding time(reported on the experience page) Onboarding gets faster when it is its own service with an automated, repeatable deployment pipeline, instead of a manual procedure that touches the whole application. Parts involved: Onboarding service, Deployment pipeline, Identity service.
Smaller blast radius(a property of the pattern) With separate data and asynchronous boundaries, a failure or a slow query in one domain no longer stalls the others. Parts involved: Identity service, Onboarding service, Reporting service, Event bus.
Reference pattern 2: keeping a busy public portal up under a spike
A public portal can see ordinary load for weeks and then a sudden spike, often with many people competing for the same record at once. Four patterns do most of the work of staying up: pooling connections, locking optimistically, caching reads and isolating faults. Switch them on and off and watch what a spike does.
The four patterns
Connection pooling
A bounded pool of reusable database connections, so a spike queues briefly instead of opening thousands of connections and exhausting the database.
Optimistic locking
Many users contend for the same record. Each writer reads a version, and only the first to write wins; the rest retry or are told, with no long-held row locks.
Caching layer
Repeated reads are served from memory, so the database mostly sees writes.
Fault isolation
Bulkheads and timeouts keep one slow dependency from tying up every worker thread.
What the model says at 8 times normal traffic
The same spike, with different protections switched on
Protections on
Slowest moment
Worst second: requests failing
Uptime in the window
Overloaded part
No protections
10 s or more
100%
38%
Database
Caching only
10 s or more
100%
40%
Worker threads
Pool, cache and optimistic locking
3.0 s
50%
43%
Worker threads
All four patterns
53 ms
0.0%
100%
None
How the model works
Normal traffic is 100 requests a second. The spike ramps up over 10 seconds, holds for 15 and ramps down over 10, inside a 60 second window. It is 8 times normal by default.
80% of requests are reads, and half of the writes aim at one hot record.
Worker capacity is 400 requests a second while a slow dependency can tie up threads, and 1,500 when it is isolated by a timeout and a bulkhead.
Database capacity is 450 operations a second, and a cache answers 92% of reads.
One hot record takes 45 writes a second under row locks and 260 with optimistic versions, which cost a few retries.
Without a bounded connection pool, too many connections slow the database itself. With a pool, extra requests wait in a queue of 300 or are turned away; without one the queue grows to 3,000.
A request slower than 5 seconds fails. A second counts toward uptime only if latency is under 2 seconds and under 2% of requests fail.
Try it: the spike simulator
Where high availability comes from
99.9% uptime(reported on the experience page) In a pattern like this, high availability under a spike comes from all four working together: no single one is enough.
These are generic reference patterns, the shapes this kind of modernization usually takes. They are not diagrams of any real system, and every number in the simulators is invented for teaching. Every host, request count and timing in this lab is invented for teaching.
The concept chapters, the machine-level chapters and the production scenarios are teaching models and simulations with invented numbers, labelled as such on the site. They are not records of real incidents. The journey below is taken from the role descriptions on this site.
The journey: six roles
Nav Info Tech (2015 to 2020, Bhopal) — Software Engineer
Trained 50+ junior developers
Delivered 6+ major releases on time
Quality Council of India (2021 to 2022, New Delhi) — Analyst Management Trainee
Managed SAP/ERP and IT projects, cutting delivery time by 15%
Worked on Swachh Survekshan 2021 performance analytics, improving city sanitation KPIs by 20%
Contributed to blockchain technology initiatives with NABL
Tashee / NIC (2022, New Delhi) — Java Developer, Team Lead
Delivered the Fancy Number Portal and the Vahaan Portal with NIC for MoRTH, at 99.9% uptime
Complinity Technology (2022 to 2025, Gurgaon) — Implementation Manager, Systems Analyst, Sr. Programmer
Led the tech stack migration from monolith to microservices
Built scalable web applications with Java, Spring Boot and Angular, improving performance by 30%
Delivered ERM/ERP portal development for BALCO
Automated legal-update tracking using JSoup, cutting manual effort by 50%
Conducted vulnerability assessments across 10+ projects
Integrated Apache Solr for advanced search, improving retrieval efficiency by 40%
Reduced enterprise client onboarding time by 20% through efficient deployment planning
Directed the monolith to microservices modernization: domain decomposition, API-first design, containerized deployment (Docker and Kubernetes)
Improved backend response times 30% under heavy logistics workloads
Coached teams on adopting AI-assisted development practices
C3iHub, IIT Kanpur (2026 to now, Kanpur) — Senior Analyst
Contributing to cybersecurity innovation programs at a nationally funded technology hub
Focus areas include application security, SOC, cyber forensics and blockchain
Concepts
The life of a request When you open a web page, a lot happens before you see anything.
Caching: fast, until it is wrong A cache is a short-term memory.
Indexes: finding without searching Imagine finding a name in a phone book with no order: you would read every page.
Monolith or microservices: choosing your blast radius A monolith is one program with everything inside it.
Scaling and queues: why busy servers fall over Think of a shop with a few tills.
Retries, and why a payment can be charged twice Networks lose messages.
APIs: contracts, versions and paging An API is a promise to the programs that use it.
Tokens: what a signature proves After you sign in, a website gives your browser a token: a small signed note saying who you are and what you may do.
Transactions: two people spending the same money Imagine a bank account with 100 in it.
The front end: why a screen stutters A web page does all its drawing and thinking on one track, called the main thread.
Containers and rollouts: health checks Modern services run in many identical containers, so one can fail without taking the service down.
Observability: why averages lie A dashboard that shows the average response time can look perfectly healthy while a real number of visitors are having a bad time.
Inside the machine
CPU, virtual memory, RAM, swap and the out-of-memory killer, and where programs become vulnerable.
The CPU: how a program really runs A processor does one small thing at a time, very fast: read the next instruction, do it, move on.
Virtual memory: what a pointer really means Every program believes it has the whole memory to itself, starting from address zero.
RAM, swap and the OOM killer RAM is limited.
Overflows and use-after-free: how memory bugs become exploits Memory bugs are mistakes about what belongs to whom.
Caches and speculation: how hardware leaks Reading RAM is slow compared with the processor, so processors keep copies of recently used memory in small, very fast stores called caches.
Exhausting the machine: CPU and memory denial of service You do not have to break into a machine to knock it over.
Secrets that live in memory When a program checks your password, the password exists in memory, in plain form, for a while.
Production scenarios
Simulated incidents to diagnose and fix.
Checkout got slow after a release It is 10:22.
Every cache entry expired at once A deploy empties the cache just as traffic is high.
A six-second blip becomes a long outage A downstream service wobbles for a few seconds and then recovers.
A bad release reaches everyone A release looks fine in testing and fails on one path in production.
The connection pool ran dry A new report makes every database query twenty times slower.
Servers that restart together A release leaks memory.
A migration locked the table A one-line schema change that took a second in testing locks the orders table for many minutes in production.
A key was committed to a public repository A developer's commit contained a cloud key, and billing now shows a stream of unfamiliar servers.