DEV Community: Krishna Yadav

From Startup to Acquisition: Lessons from Building and Selling an eCommerce Platform

Krishna Yadav — Mon, 05 Oct 2026 17:02:26 +0000

In February 2014 I was twenty-two, halfway through an M.Tech, and convinced I could build a marketplace that would change how local vendors sold online. Three years later the platform was serving eighty-plus vendors, processing real money, and I signed the papers that handed it to someone else.

This is the short version of that story, and the seven things it taught me.

The Setup

Small vendors in our region had no affordable way to sell online. Big marketplaces charged steep commissions and buried small sellers. We wanted to build a multi-vendor platform where each shop got its own storefront with shared logistics, payments, and traffic.

My co-founder handled business. I handled everything that touched a terminal. We bootstrapped — no angel round, no incubator. Every hour of engineering time came directly out of the hours I was supposed to spend on coursework.

Building on a Twelve-Dollar VPS

I picked Java and Spring for the backend, MySQL for persistence, jQuery for the frontend. Not trendy, but I trusted it wouldn't collapse at midnight when I was the only person on call.

The MVP took ten weeks of nights and weekends. One Spring monolith, one database, one Tomcat server on a VPS that cost twelve dollars a month. It was ugly. It worked.

The first real challenge was payment integration. Two Indian payment gateways, each with its own callback format, retry logic, and definition of "success." I wrote an adapter layer that normalized both into common internal events — PAYMENT_CAPTURED, PAYMENT_FAILED, PAYMENT_REFUND_INITIATED — so the rest of the order pipeline didn't care which gateway handled a transaction. That pattern ended up being the most reusable code in the entire system.

Scaling and Cracking

Each new vendor exposed a new edge case. Weight-based items. Variant pricing. Bundle deals. Every feature request was a negotiation between "this helps one vendor" and "this complicates things for everyone."

Around vendor forty, the monolith started cracking. Page loads crept past three seconds. I extracted the inventory service into its own process with its own database. Not a full microservices migration — one pragmatic extraction that relieved the biggest bottleneck.

Meanwhile I was attending lectures from 9 AM to 1 PM, building the platform from 2 PM to midnight, and squeezing thesis research into whatever gaps remained. The saving grace: every distributed systems concept from the M.Tech curriculum — consistency models, fault tolerance, CAP theorem — I was seeing in production the same week I read about them in papers. The gap between theory and practice wasn't a gap. It was the same Tuesday.

The Exit

By early 2017 the platform was profitable but growth had plateaued. A regional eCommerce company approached us. They wanted our vendor network and our technology — specifically the vendor management system and the payment adapter layer, which they said would save them six to eight months of development.

The negotiation took two months. We closed in May 2017. The terms were fair. The vendors kept their storefronts, the customers kept their accounts. I walked out with no regrets and a clear picture of what I wanted next: building at larger scale, which eventually led me to Oracle Financial Services, Kotak Securities, and AirAsia where I now work on systems processing 130 million daily transactions.

Seven Lessons for Technical Founders

1. Ship the ugly version first. Our MVP was architecturally embarrassing. It was also live, collecting payments, and teaching us what users actually needed. The beautiful rewrite can happen after you've proven the business.

2. Pick boring technology. Java and Spring in 2014 won zero hackathons. But when our payment integration broke at midnight, I could find a Stack Overflow answer in under a minute. Boring technology compounds reliability.

3. Solve the class, not the instance. When vendor thirty-seven asks for a feature, ask what general problem it represents. Build the general solution or don't build it at all. Every special case is a maintenance liability that outlives whoever requested it.

4. Wrap every external dependency in an adapter. Payment gateways, shipping APIs, SMS providers — they will change their interfaces, go down, or get replaced. Your codebase should never know or care which vendor sits behind the adapter.

5. Cofounder alignment beats cofounder skills. We never argued about direction because we agreed on the fundamentals before we started: bootstrap, stay profitable, build something vendors actually use. Technical skills can be hired. Strategic alignment cannot.

6. Know your exit conditions before you need them. We didn't have a formal trigger for when to sell, and that made the decision more emotional than necessary. Write down the conditions under which you'd sell, shut down, or raise money — before you launch.

7. Burnout is not a badge of honor. I pushed through it because I was young and stubborn. One full day off per week would not have killed the company and would have made me a better engineer the other six days.

That startup gave me scars and skills in roughly equal proportion. If you're building something right now — side project, startup, internal tool at a company that doesn't appreciate it — the work compounds. The code you're embarrassed by today teaches you to write something better tomorrow.

Originally published on krishnakky.com — the full version has more detail on the technical architecture, payment integration patterns, and the acquisition negotiation.

AI-Driven Development: Running Autonomous Agents Across a Microservices Codebase

Krishna Yadav — Mon, 05 Oct 2026 16:57:07 +0000

At AirAsia, I own production microservices on the Manage My Booking platform — flight changes, fare summaries, price-slash, post-booking ancillaries. Over a dozen services, each with its own repo, pipeline, and accumulated quirks. The platform processes 130 million requests a day.

My problem was never writing code. It was the context-switching overhead. Bouncing between a fare-calculation refactor, a circuit breaker fix three repos over, and a schema migration for the ancillary service — every switch cost 20–30 minutes of mental reload. Entire days evaporated into friction.

I started using Claude Code not to write code for me, but to keep multiple workstreams moving in parallel. It operates directly in the terminal — reads the codebase, runs commands, writes files, stages changes. An agent, not an autocomplete engine.

Permission Scopes: The Non-Negotiable First Step

You cannot hand an AI agent unrestricted access to a production codebase. That is how you get a force-push to main at 2 AM.

I set up scoped permissions per project in .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Bash(npm run test*)",
      "Bash(npm run lint*)",
      "Bash(mvn test*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git log*)",
      "Bash(git add -p*)"
    ],
    "deny": [
      "Bash(git push*)",
      "Bash(git checkout main*)",
      "Bash(rm -rf*)",
      "Bash(docker*)"
    ]
  }
}

The agent can read, write, edit, run tests and linters, view diffs, and stage changes. It cannot push, switch to main, delete directory trees, or touch Docker. Every push and merge goes through me. Payment-adjacent services get tighter restrictions. Internal tooling repos are looser.

The Three-Phase Model

I restructured feature delivery into three phases:

Inception (human only). I define the scope, draw sequence diagrams, identify affected services, and write interface contracts. This produces a spec document — the agent's input. Thirty to sixty minutes here, and the quality directly determines how useful the agent is downstream.

Construction (agents + review). Each agent gets a spec, a repo, and constraints. I run parallel terminal sessions — one agent per service:

Terminal 1: Agent on booking-service, implementing the new endpoint
Terminal 2: Agent on pricing-engine, adding fare calculation logic
Terminal 3: Agent on ancillary-catalog, updating schema and data layer
Me: Reviewing diffs, running integration tests, handling cross-service architecture decisions

The agents don't talk to each other. I am the coordination layer. When the pricing agent finishes, I review it and feed interface changes to the booking agent as context.

Operations (human only). Post-merge monitoring, production validation, performance profiling. I watch dashboards, check distributed traces in Zipkin, validate circuit breaker behavior. AI agents have no business in production operations.

Results After Six Months

Feature delivery time dropped ~40%. Cross-service features that took 4–5 days now take 2–3. The reduction comes from parallel Construction — three repos at once instead of sequential.

Unit test coverage increased. Writing tests is mechanical work agents handle well. I used to skip edge-case tests when tired. The agent does not get tired.

Code review quality improved. When I write code, I review it with the same mental model — and miss my own blind spots. Agent-written code gets genuinely fresh-eyed review. The separation between author and reviewer becomes real.

Commit history became cleaner. Selective staging and single-purpose commits made git bisect actually useful.

Not everything parallelizes. Tightly coupled changes where Service B depends on Service A's final interface still bottleneck. Those still see gains, but more like 15–20%.

Pitfalls Worth Knowing

The agent optimizes locally. It writes correct code for the service it sees while introducing interface mismatches with services it cannot see. Cross-service contracts must come from a human holding the full system model.

Spec quality is the bottleneck. "Add error handling to the booking endpoint" gets generic try-catch blocks. "Return HTTP 409 with BOOKING_CONFLICT when the fare class is unavailable, include available fare classes in the response body, emit a Kafka event to pricing-update" gets exactly what you need.

Don't let agents refactor while implementing. Mixed diffs — new functionality tangled with cleanup — are impossible to review. Implement against the existing structure; refactor in a separate PR.

Check in every 15–20 minutes. Not because the agent will break something catastrophic (permission scopes prevent that), but because a five-minute course correction at the 20-minute mark beats throwing away 90 minutes of wrong-direction implementation.

The Bigger Picture

This is not about AI replacing developers. It is about restructuring the workflow so human attention goes where it matters: architecture, system-level reasoning, production reliability. The mechanical act of translating a well-defined spec into working code with tests — that is what agents handle well. At the scale we operate at AirAsia, that mechanical work was eating a disproportionate amount of my time.

The spec-writing phase now takes longer than it used to. That tradeoff is worth it.

Originally published on krishnakky.com. Read the full version with detailed Git integration workflow, war stories, and what I'm experimenting with next.

Building Microservices at 130 Million Requests Per Day

Krishna Yadav — Mon, 05 Oct 2026 16:56:59 +0000

I've spent the last three-plus years building and operating the microservices behind AirAsia Move — the travel super-app that handles flights, hotels, and ancillaries for millions of travelers across Southeast Asia. The system processes over 130 million requests per day, roughly 1,500 requests per second sustained, with spikes well above that during flash sales.

I own services on the Manage My Booking platform: flight changes, fare summaries, price-slash features, post-booking ancillaries. A single user action like changing a flight can fan out to eight or nine downstream calls. At this scale, the engineering problems aren't about whether your code compiles. They're about what happens when one of those downstream services is 200ms slower than usual.

Circuit Breakers with Resilience4j

The pattern that proved its weight in gold was the circuit breaker. We use Resilience4j across all Spring Boot services — if a downstream service starts failing, stop calling it instead of piling up timeouts that cascade through the system.

@CircuitBreaker(name = "pricingService", fallbackMethod = "cachedFareFallback")
public FareSummary getFareSummary(String bookingId) {
    return pricingClient.fetchFare(bookingId);
}

private FareSummary cachedFareFallback(String bookingId, Throwable t) {
    log.warn("Pricing service unavailable for booking {}, using cache", bookingId);
    return fareCache.getLastKnown(bookingId)
        .map(fare -> fare.withStaleFlag(true))
        .orElseThrow(() -> new ServiceUnavailableException("No cached fare available"));
}

We pair breakers with fallbacks. If the pricing service is down, the user still sees a fare — it might be a few minutes stale, but that beats a blank screen or a 500.

We tuned thresholds through load testing with JMeter. The defaults were too aggressive and tripped breakers during normal latency variance. A 50% failure rate over a sliding window of 20 calls, with a 30-second open-state wait, matched our actual traffic pattern.

Distributed Tracing

When a request crosses ten services, debugging without distributed tracing is a lost cause. We use Spring Cloud Sleuth for trace propagation and Zipkin for visualization. We sample 10% of traces in production — at 1,500 RPS, that's 150 traces per second, more than enough to spot patterns.

The biggest tracing win wasn't debugging individual slow requests. We noticed every Tuesday between 2–4 AM UTC, latency spiked on the inventory service. A batch job was running full table scans on the same database the API was reading from. Moved the job to a read replica, spikes gone.

The Cascading Timeout

During a Diwali sale, the payment gateway started responding 300ms slower than usual. Not enough to fail — just enough to back up our thread pool. We had a fixed pool of 200 threads with a 5-second payment timeout and a bounded queue of 500. When every thread was blocked on slow payment calls, the queue filled. Upstream services calling us started timing out. Within 90 seconds, three services were effectively down.

The root cause wasn't the payment gateway. It was our thread pool and timeout configuration.

We made three changes:

Cut the payment timeout from 5s to 2s. If it hasn't responded in 2 seconds during peak load, it's not going to.
Added a bulkhead — isolated the payment call to its own thread pool so one slow dependency can't starve everything else.
Switched the circuit breaker to a time-based sliding window so it reacts faster during traffic spikes.

The Memory Leak

Our flight-change service was getting OOMKilled by Kubernetes every 48 hours. Two days of profiling with JVisualVM found a ConcurrentHashMap used as an in-memory cache with no eviction. Every unique booking ID got cached and never expired. Under sustained 1,500 RPS, it grew until the JVM ran out of heap.

Five lines of code, two days of investigation:

Cache<String, FareSnapshot> fareCache = Caffeine.newBuilder()
    .maximumSize(50_000)
    .expireAfterWrite(Duration.ofMinutes(10))
    .build();

What I'd Do Differently

Contract testing from day one. When Service A renames fare_amount to fareAmount, both services' unit tests pass. Staging explodes. Consumer-driven contract tests catch this at build time.

Structured logging earlier. Searching Kibana for a booking ID across 10 services when half log bookingId=ABC123 and the other half log Processing booking ABC123 for user xyz is painful. Consistent field names should be a service template requirement on day one.

More aggressive load shedding. At 90% capacity, return 429s for low-priority endpoints and keep booking and payment paths fully served, instead of letting everything degrade equally.

The Takeaway

Building microservices at this scale is about understanding failure modes. Every pattern — circuit breakers, tracing, async messaging, bulkheads — exists because something broke in production and we needed it to not break the same way again. The system processes 130 million requests a day not because we got the design right on the first try, but because we built the instrumentation to see what was breaking and the patterns to contain the blast radius.

Originally published on krishnakky.com — the full version has additional code examples, Kafka event-driven architecture details, and a third production war story about consumer group rebalances.