Tag
Everything tagged Systems Engineering, most recent first.
50 entries
Test before release. Enforce at runtime.
Talk on governance for tool-using AI agents: why a correct answer can still be unsafe, the three checks that catch it in CI, and the runtime gate that stops it before the action runs.
Artifact Evaluation Committee member for ACSAC 2026, the 42nd IEEE Annual Computer Security Applications Conference, evaluating two artifacts for reproducibility.
Artifact evaluator for ASE 2026 (IEEE/ACM International Conference on Automated Software Engineering).
AI Engineer World's Fair 2026 talk: agents need feature flags. We ship the most behavior-changing systems we have ever built, agents that send email, move money, and modify databases, with none of the canary, segment-targeting, and kill-switch discipline web teams settled a decade ago. The talk lays out six flag types for the six behavior surfaces an agent has, a rollout playbook with the numbers to track, and why a stop button is now required by law.
AI Engineer World's Fair 2026 talk: your coding agent is creating review debt, the accumulating gap between the code an agent produces and the code humans have actually reviewed, trusted, and understood. Five signal families and ten deterministic checks turn that gap into a single defensible score, validated across 524 real pull requests.
Agents are in production and doing privileged things, but the guardrails did not arrive with them. This PlatformCon talk lays out a Java and Spring Boot pattern that makes an agent quote a versioned tool contract before any tool runs, with a gateway that validates, governs, and audits every call.
A three-layer evaluation framework in Java + LangChain4j for AI-agent trust testing: policy compliance, judge-based answer safety, and tool-trajectory validation, wired into CI as a build-time gate.
Once messages can be retried, a new problem appears: a payment could be charged twice, or lost entirely. This piece is about the three promises a messaging system can make (at-most-once, at-least-once, exactly-once), why exactly-once is really achieved by making the work idempotent, and why order matters. It closes the messaging arc.
A from-the-ground-up look at delivery guarantees, the last piece of the messaging arc. The three promises a system can make: at-most-once (a message may be lost but never duplicated), at-least-once (never lost but may arrive more than once), and exactly-once (once and only once). Why real systems run at-least-once and reach exactly-once in practice by making each operation idempotent, so a retried request has no extra effect, the way a Stripe idempotency key prevents a double charge. Why ordering matters, and what Amazon SQS standard and FIFO queues, Apache Kafka, and application-level idempotency keys actually guarantee. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
A queue empties as it is read, so a note is gone once someone handles it. A log does the opposite: it keeps every record, in order, and lets anyone read back from any point, even a service that starts up next year. That is the idea behind Kafka. Here is the append-only log, offsets and replay, partitions and ordering, and consumer groups.
A from-the-ground-up look at the event log, the idea behind Apache Kafka. A log is append-only and keeps every record for a retention window whether or not anyone has read it, the opposite of a queue that empties. Each record has an offset, and every reader keeps its own offset, so a new service can replay from the beginning and a service that was down can catch up from where it left off. Partitions split the log so many producers and consumers work at once while order is kept within a partition, and consumer groups either split the work or each receive a full copy. Everyday analogies, a hand-drawn diagram, a visualizer per idea, and what Kafka really does.
A queue hands each note to exactly one worker. Sometimes you need the opposite: one thing happens and many services all need to hear it. That is pub/sub. Here is fan-out, how it differs from a queue, the queue-per-subscriber pattern that makes it durable, and how a notification system is built on it.
A from-the-ground-up look at pub/sub. Fan-out: a publisher posts one event to a topic and every subscriber gets its own copy, decoupled from the publisher. Why that is the opposite of a work queue (distribute vs broadcast), the queue-per-subscriber pattern (SNS to SQS) that gives each subscriber isolation and its own retries, and how a notification system fans an event out to email, SMS, and push. Everyday analogies, a hand-drawn diagram, a visualizer per idea, and what Amazon SNS, Google Cloud Pub/Sub, and Redis pub/sub really do.
Not every job should happen while the user waits. A queue lets one side drop off work and walk away, and another side pick it up and do it later, at its own pace. Here is how a message queue absorbs a rush, spreads work across many workers, survives a crash, and quarantines the messages nobody can handle.
A from-the-ground-up look at message queues. Why you decouple the caller from the doer, how a queue absorbs a traffic spike (load leveling), how a pool of competing consumers scales the work, why a message is hidden and redelivered (visibility timeout, acknowledgments, at-least-once delivery and idempotency), and how a dead-letter queue quarantines poison messages. Everyday analogies, a hand-drawn diagram, a visualizer per idea, and what Amazon SQS and RabbitMQ actually do.
Every cache so far lived next to your database. The last one lives next to your users, thousands of miles closer than your servers. A CDN keeps copies of your content in cities all over the world, so the trip is short. Here is how it works, one idea at a time, each with its own analogy and visualizer.
A from-the-ground-up look at CDNs, the cache nearest your users. Why serving from a nearby edge beats a round trip to a far origin, how content reaches the edge (pull vs push), how long the edge keeps it (TTL and Cache-Control, max-age vs s-maxage, stale-while-revalidate), the cache key and how marketing query params fragment the cache, purging and versioned URLs when content changes, and the origin shield that turns a thundering herd of edge misses into one origin fetch. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
A cache that works beautifully at steady state can still fall over in a single instant. The moment one very popular key expires, thousands of requests miss at the same time and stampede the database at once. Here is the problem, and the three ways to keep that spike from taking the system down, each with its own analogy and its own visualizer.
A dedicated look at the cache stampede, or thundering herd. Why a single hot key expiring turns thousands of harmless cache hits into a synchronized flood of database queries in the same instant, and why that spike can take a system down even when average load is fine. Then the three standard defenses, each analogy-first with a visualizer: locking and single-flight (only the first miss refetches, the rest wait), stale-while-revalidate (keep serving the stale value while one background refresh runs), and probabilistic early expiration (XFetch, where one request refreshes early before the herd forms), plus jittered TTLs for synchronized warm-ups.
A cache miss is slow but correct. A stale cache hit is fast and wrong, and wrong is worse. Invalidation is the work of making sure the copy in the cache still matches the truth in the database. Here are the ways to do it, each with its own analogy and its own visualizer.
A dedicated look at cache invalidation, the hard half of caching. Why a stale hit is worse than a miss, then the four strategies to keep a cache honest: TTL expiry (bounded staleness), write-through (update on write), invalidate-on-write (delete the key and let the next read refill), and versioned or immutable keys (bump the version, never edit in place). Everyday analogies, a hand-drawn stale-window timeline, and visualizers for the delete-on-write cycle and versioned keys. Why the races make it genuinely hard, and a tee-up to the stampede.
A cache is small on purpose, so it is almost always full. To store one more thing it has to throw one thing out, and the whole art is choosing which. Three policies answer that question in three different ways: LRU by recency, LFU by frequency, TTL by age. Here is each one, with its own analogy and its own visualizer.
A dedicated look at cache eviction. Why a cache must forget, then the three policies each with its own everyday analogy and interactive visualizer: LRU (recency, a desk), LFU (frequency, a bestseller shelf), and TTL (age, milk with an expiry date). A worked example for each, a hand-drawn diagram showing the same cache evict three different items, guidance on which to use when, and what Redis and memcached run in production.
The fastest work is the work you never do. A cache keeps a copy of an answer close by, so the next time someone asks, you hand it over instead of computing it all again. Here is how caches actually work: where they live, how reads and writes flow through them, and why they have to forget things.
A from-the-ground-up look at caching. Why it works (keep the answer close), where caches live (browser, CDN, app, database), the cache-aside read pattern (the hit and the miss), the three write patterns (through, back, around), and eviction (why a full cache must forget, with LRU). Everyday analogies, a hand-drawn diagram, and a visualizer per idea. The hard parts (invalidation, stampedes) and CDNs get their own pieces next.
Generating working MCP servers straight from the OpenAPI specs you already have: the mechanical field mapping, why it takes a library and not a script, the production traps, and the guardrails to set before an agent touches real users.
Sometimes you want the opposite of spreading traffic evenly: send the same client, or the same request, to the same server every time. That is stickiness, and it runs from a simple hash all the way to the elegant trick of consistent hashing.
A dedicated look at the sticky load-balancing rules, the ones that send the same key to the same server. Why you want it (sessions and caches), then each rule with its own analogy and visualizer: source-IP hash, URL hash, the reshuffling problem, consistent hashing (the ring), Maglev (a fast table), and cookie-based sticky sessions. Part two of two; part one covered the even-spreading rules.
The load balancer's first job is picking which server gets each request. There is a small family of rules for that, from dealing cards in turn to glancing at two servers and choosing the emptier. Here they are, one at a time.
A dedicated look at the load-balancing algorithms that spread traffic across servers. The static-vs-dynamic split, then each rule in turn with its own analogy and visualizer: round-robin, weighted round-robin, least-connections, least-response-time, and power-of-two-choices. Part one of two; part two covers the sticky ones (hashing and affinity).
One front desk that every request passes through, so each service behind it does not have to check IDs, enforce limits, and route traffic on its own. It is also where a confusing family of names lives: gateway, reverse proxy, load balancer.
A deep look at the gateway, the third building block from the request-path overview. The cross-cutting jobs it does once for everyone (authentication, routing, TLS, rate limiting), how a gateway relates to a reverse proxy and a load balancer (they are one overlapping family), the difference between a forward and a reverse proxy, and where rate limiting fits. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
Computers find each other by number, not by name. DNS is the phone book that turns guptasachinn.com into an address a machine can dial, and it is quietly one of the most important systems on the internet.
A deep look at DNS, the building block introduced in the request-path overview. How a name becomes an IP address, the lookup chain from your resolver up to the authoritative server, why answers are cached (TTL), and how DNS does more than lookups: sending you to the nearest server and routing around a dead one. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
One web address, but many identical servers behind it. The load balancer is the host that decides who goes where, notices when a server dies, and can even read a request to route it. Here is everything it does.
A dedicated look at load balancers, the building block introduced in the request-path overview. How it chooses a server (round-robin, least-connections, weighted, sticky), how health checks notice a dead server and route around it, the difference between layer 4 and layer 7 balancing (route by the envelope or open the letter), and how the load balancer itself avoids being a single point of failure. Everyday analogies, a hand-drawn diagram, and a visualizer per idea.
Type a web address, hit enter, and a page appears. Behind that is a small journey: your request must find one server out of millions, then get past the front door. Three things make it happen: DNS, a load balancer, and a gateway.
Day three of the System Design series, and the first building blocks. When someone uses your system, the very first thing that happens is their request finding a server. This walks the journey: DNS turns a name into an address, a load balancer spreads requests across servers, and a gateway is the shared front door for auth, rate limiting, and routing. Each explained with an everyday analogy first, a hand-drawn diagram, and its own interactive visualizer.
How big is this thing? You do not count, you estimate, the same way you guess jelly beans in a jar. Three quick multiplications tell you whether you need one server or a thousand.
Day two of the System Design series, and step two of the routine on its own: estimation. Learn to size a system with three numbers, throughput (requests per second), storage, and bandwidth, using rounded napkin math. Worked all the way through on the link shortener from day one. With a jelly-bean analogy, a hand-drawn diagram, and an interactive visualizer that rolls the numbers up as you go.
Faced with 'design something big', most people freeze or jump straight to a database. A good doctor never works that way: they run the same routine every time. Here is that routine for systems, in six steps.
Day one of the System Design series. Before any load balancers or databases, you need a way to think. This is the six-step routine, scope, estimate, API, data model, high-level design, then deep dive, walked through on a real example (a link shortener). With an everyday analogy, a hand-drawn diagram, and an interactive visualizer that shows the routine turning a vague prompt into a design.
Artifact evaluator for CAV 2026 (Computer Aided Verification).
An incident-remediation agent behind a security envelope
A self-healing microservices agent that reasons over telemetry, deploy history, and logs via MCP and remediates production incidents behind an RBAC, ACL, OAuth, and human-approval envelope.
Elevated to Senior Member grade of the IEEE for significant contributions to the profession.
Mentored teams building software for nonprofits at Opportunity Hack.
Blast radius and incident-to-deploy correlation
A platform that maps service topology, indexes logs and traces, correlates incidents to deployments, and computes blast radius, giving evidence-grounded answers to 'why did this deploy fail?' and 'what breaks if I change this?'
Zero-disruption migration across the entire seller ecosystem
Architecture and delivery on eBay's next-generation billing platform: leading the seller-and-balance migration, rearchitecting the public API layer for high-traffic reliability, and building the reconciliation and data pipelines the platform runs on.
Credit-card portfolio optimizer with certified optimality
Credit-card portfolio optimization via mixed-integer linear programming, with solver-certified optimality and structurally verified explanations that cite only solver-emitted evidence.
Multi-hazard risk, and a model that predicts it
A free, open-source multi-hazard risk assessment for any US address (HazardPrep) paired with an XGBoost engine that predicts FEMA disaster declarations up to 90 days ahead (HazardCast).
Java & Android heap-dump analysis in VS Code
A VS Code extension for Java and Android heap-dump analysis: a native Rust engine, 11 interactive views, a SQL-like query language, and an AI assistant, all running locally on production-sized dumps.
A walk through the Singleton pattern in Java, from lazy initialization to thread-safe and double-checked locking, the Bill Pugh approach, and enum-based singletons, including how each holds up against serialization and reflection.
A field-engineering note on the precision losses double quietly introduces in financial code, when BigDecimal is the right move, and the rounding patterns that keep statements reconcilable.
Ten Spark SQL capabilities with no direct Oracle equivalent, from anti joins and explode to higher-order array transformations, and where they simplify real data pipelines.
Five anti-patterns I see in production code review: why they matter for maintainability and reliability, and the minimal-cost refactors that close them without breaking calling code.
A practical reference of 25 Git commands for everyday version control and collaboration, with the scenario where each one earns its place.
How the Karatsuba algorithm multiplies large numbers faster than long multiplication, trading one multiplication for a few additions to bring the cost from quadratic down to about n^1.585.
What Java's volatile keyword actually guarantees (visibility of writes across threads) and what it does not (atomicity and mutual exclusion), and why compound operations still need synchronization.
How Java 17 turns the old switch statement into a switch expression, with arrow labels, yield, and exhaustiveness checks that make branching cleaner and safer.
A Java concurrency note on when to reach for Thread versus ThreadLocal, how per-thread isolation avoids shared-state bugs like the classic SimpleDateFormat race, and how the two work together for thread-safe code.
Spot Award at eBay for a seamless billing migration off a legacy system.
LDD referral reporting and compliance for Walgreens specialty pharmacy
A web-based platform for reporting Limited Distribution Drug (LDD) referrals at specialty pharmacy sites: integrating with the core dispensing system for near real-time prescription tracking, auditing, and manufacturer-contract compliance.
STQC-certified e-voting for India's listed companies
A government-authorized, STQC-certified electronic voting platform that lets shareholders of publicly listed companies vote on corporate resolutions digitally across AGMs, EGMs, and postal ballots.
Community volunteering with Feed My Starving Children.
Volunteered in TCS Maitree city-cleanup, tree-planting, and beach-cleanup drives in Mumbai.
Volunteered teaching foundational Hindi to children from under-resourced families in Pune, India.
Spot Award at TCS for building an e-voting website.
