Forem: Ujjawal Tyagi

Why We Rarely Use GraphQL (And When We Do)

Ujjawal Tyagi — Fri, 24 Apr 2026 21:55:30 +0000

GraphQL is a great tool. It is also the wrong default for 90 percent of the products we ship at Xenotix Labs (https://www.xenotixlabs.com). Here is our reasoning after 30+ production apps.

When GraphQL wins

GraphQL genuinely helps when (1) you have many different clients with very different data shape requirements, (2) your data has deep nested relationships that REST endpoints would over-fetch on, and (3) your team has the discipline to maintain a schema layer on top of your services. For Shopify, Facebook, GitHub, these conditions are true. For most startup MVPs, none of them are.

Why we default to REST

For an Indian founder's MVP: a single mobile app, a single admin dashboard, both built by the same team, with <100 endpoints. REST is the simpler choice. Every engineer on the planet knows how to debug a REST call. OpenAPI specs are easy to generate. Versioning via URL prefix is straightforward. Caching via HTTP semantics is free.

We use REST for ClaimsMitra (114+ endpoints across 8 services), Legal Owl (LegalTech with 7 user personas), Veda Milk (D2C subscription), Cricket Winner (real-time cricket on Kafka + WebSockets, with REST for non-realtime), and Growara (WhatsApp automation). No GraphQL anywhere.

Where we do use GraphQL

We shipped one project on GraphQL end-to-end: an educational content aggregator with multiple content sources (YouTube, PDFs, quizzes, user-generated notes) and 4 different client apps (student, teacher, parent, admin). Each client wanted different slices of the same underlying data. GraphQL saved us from writing 4x the REST endpoints.

Even there, we kept the GraphQL layer thin—it's a gateway over REST microservices, not a full rewrite of the business logic. The GraphQL resolvers call our internal REST APIs and compose the response. This lets us stay REST-native on the service side while still serving a GraphQL surface to clients that need it.

What to watch out for

GraphQL's complexity shows up in auth, error handling, and caching. Auth: instead of one middleware per endpoint, you need per-field or per-resolver auth, which is more code and more edge cases. Error handling: a GraphQL response can be partially successful, which is hard to reason about. Caching: you lose HTTP caching and have to invent your own.

Also: N+1 queries are easier to stumble into than you'd think. DataLoader helps but isn't automatic; we've debugged GraphQL perf regressions that would have been impossible in REST.

The practical rule

If you're a founder with 1 mobile app, 1 web dashboard, and <150 API endpoints, default to REST. Reach for GraphQL when you have 3+ client surfaces with materially different data needs, or when your team genuinely wants the schema-first discipline.

About Xenotix Labs

We ship 30+ production apps from India. Flutter, Next.js, Node.js on AWS. Veda Milk (D2C dairy), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app), ClaimsMitra (114+ REST APIs), Growara (AI WhatsApp automation), 7S Samiti (offline-first AI tutor for rural India). If you're shipping an MVP and want the simplest stack that works, visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

How We Ship 30+ Apps with 8 Engineers: Our Full-Stack Engineer Model

Ujjawal Tyagi — Fri, 24 Apr 2026 21:48:15 +0000

Most agencies scale by hiring specialists. Frontend engineers here, backend there, DevOps in a separate pod, a QA team downstream. At Xenotix Labs (https://www.xenotixlabs.com) we went the other way—we hire full-stack engineers who own a product vertically from Figma handoff to production deployment. Here is why, and what that looks like in practice.

Why full-stack

When you split a product across 4 specialists, 70% of your calendar becomes coordination. Hand-off from design to frontend. Hand-off from frontend to backend. Hand-off from backend to DevOps. Every hand-off is a meeting, a spec, and a week of latency. For a 6-week MVP, you literally cannot afford that latency.

Our engineers own a product vertically. One engineer takes the Figma, builds the Flutter screen, writes the Node.js endpoint, runs the database migration, deploys to AWS, and monitors the resulting metric. Same person. This cuts coordination cost by 4x and lets us run each product with a team of 2–4 instead of 8–10.

What full-stack means to us

We define full-stack as: strong in one primary stack (backend or frontend), productive in adjacent stacks, and comfortable owning deployment. Not a 10x engineer myth. Just a T-shape. Every engineer on our team can ship a Next.js component, write a Node.js API, add a Postgres migration, deploy to AWS Fargate, and debug a production issue. Some are deeper in Flutter, some in backend, some in DevOps, but nobody is a silo.

Hiring for this

We don't hire based on title. We run a 3-stage process: a take-home building a simple feature end-to-end (Flutter + Node.js + Postgres, deployed anywhere), a pair-programming session where the candidate and I extend one of our real products (scrubbed), and a final conversation about product judgment. We ignore language-specific puzzle questions. We want to see if the candidate makes good trade-offs under time pressure.

How the team scales

Every engineer runs 1–2 products at any given time. We rotate engineers across products every 6–12 months so people don't get locked into one domain and institutional knowledge doesn't stagnate. For complex products (Legal Owl, ClaimsMitra) we staff 3–4 engineers instead of 1–2. For MVPs (single-founder ideation stage) we often staff 1 engineer plus a design partner.

The counterexamples

This model falls apart for apps heavy in native mobile SDK integration (AR, deep Bluetooth work). For those we do bring in iOS and Android specialists. It also falls apart for apps where we need 24/7 production monitoring; we rely on managed services plus on-call rotation through the engineering team instead of a dedicated ops team.

What we've shipped this way

30+ products including Veda Milk (D2C dairy subscription), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app with 7 user personas), ClaimsMitra (insurance platform with 114+ REST APIs), Growara (AI WhatsApp automation), and 7S Samiti (offline-first AI tutor for rural India).

Hiring us

If you're a founder who values shipping speed over org-chart complexity, we'd love to talk. We are 15+ engineers, full-stack by design, Flutter + Next.js + Node.js on AWS. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Microservices Mistakes I Wish Someone Had Warned Me About

Ujjawal Tyagi — Fri, 24 Apr 2026 21:45:19 +0000

Every team I've talked to that adopted microservices in the last five years has the same arc: enthusiasm at month one, regret at month nine, sober refactoring at month eighteen. At Xenotix Labs we've shipped 30+ platforms on microservices, and we've made every one of these mistakes at least once. Here are the ones I wish someone had told us about earlier.

Mistake 1: Splitting too early

The loudest signal that you're splitting too early: you can't ship a feature without coordinating four pull requests across three repos. Microservices made sense on the architecture diagram, but in practice, your team's natural unit of work spans services.

Fix: when in doubt, start as a modular monolith with clear internal boundaries. Split out a service when one of three things is true:

A separate team owns it
It needs to scale independently from the rest of the system
Its deployment cadence is fundamentally different (e.g., a low-risk service ships hourly, the rest ships weekly)

If none of those apply, you're paying microservices tax for no benefit.

Mistake 2: Splitting along the wrong seams

We split a system into user-service, address-service, and subscription-service. Made sense on paper. In practice, every "create subscription" call had to chain through all three. Latency tripled. Failure modes multiplied. A bug fixed in user-service broke address-service two weeks later.

The right seam is usually a workflow boundary, not a data-table boundary. "Customer" was the workflow. We re-merged the three back into a single customer-service and moved on with our lives.

Mistake 3: Sync HTTP everywhere

When every service calls every other service over synchronous HTTP, you've built a distributed monolith. Latency adds up. One slow service blocks the whole chain. The blast radius of an outage in payments-service reaches notifications-service even though they have nothing to do with each other.

Fix: prefer events for cross-service communication. Service A publishes "order-created". Service B consumes it on its own schedule. They don't know about each other; they know about the event shape.

We use RabbitMQ for task-style events and Kafka for high-throughput log-style events. Either way, the principle is the same: services communicate through events, not direct calls.

Mistake 4: No idempotency

Distributed systems retry. Networks fail mid-request. Workers die mid-process. If your APIs are not idempotent, retries silently create duplicate orders, double-charge customers, and generate phantom inventory.

Fix: every write API takes a client-generated idempotency_key (a UUID). The server stores the key + response. If the same key arrives again, return the cached response.

This costs one column and 10 lines of code. It saves you from 2 a.m. incidents for the rest of the company's life.

Mistake 5: Database per service, taken too literally

The textbook says "each service owns its own database." In practice, this leads to absurdities: now you need to synchronize the customer's address between three databases. You build sync jobs. They lag. Reports are inconsistent.

Fix: a shared database is fine when the data is naturally shared. The rule we use: each service has full ownership over the write path for its tables, but reads can come from a shared analytical replica. Keep transactional writes per-service; let reads scale separately.

Mistake 6: No request tracing

A microservices outage looks like this: "orders are slow." Now you have to figure out which of 12 services is the bottleneck. Without distributed tracing, you're guessing.

Fix: every inbound request gets a trace_id. Every downstream call propagates that trace_id. Every log line includes it. Every span shows up in OpenTelemetry / Jaeger / Honeycomb / Datadog.

With tracing, an outage is a 5-minute investigation. Without it, it's a 5-hour war room.

Mistake 7: Versioning by neglect

"We'll figure out versioning when we need it" is how you end up with 14 services that all crash if you change a field.

Fix: from day one, every API and every event has a version. Add fields, never rename. Deprecate slowly. Maintain backward compatibility for at least one full release cycle. Treat your internal APIs with the same discipline as external ones.

Mistake 8: One service, one database, one team — but no on-call

Microservices distribute the system. They also distribute the responsibility for keeping it up. A service without a clear on-call rotation is a service that goes down on a Sunday and nobody notices until Monday morning.

Fix: every service has a primary owner. The owner is on the on-call rotation for that service. Alerts go to the owner first. The owner's commitment: a P1 alert is acknowledged within 15 minutes, regardless of the time.

This is hard. It's also what makes microservices viable as a long-term architecture rather than a long-term liability.

What we'd tell our past selves

Microservices are a tool to scale teams and isolate failure domains. They are not a goal. If you don't have multiple teams, you don't need them. If you have multiple teams but no real isolation needs, you may not need them.

When you do need them: split slowly, split along workflow boundaries, prefer events over sync calls, make everything idempotent, trace every request, version every interface, and put a real owner on every service.

Need help architecting your stack?

Whether it's a greenfield platform or a monolith you're carefully splitting, Xenotix Labs has shipped microservices architectures across D2C commerce, real-time sports, healthtech, edtech, and more. We've made every mistake on this list and learned from each one. Reach out at https://xenotixlabs.com.

Scaling WebSockets to 100k Connections: Lessons from a Real-Time Cricket App

Ujjawal Tyagi — Fri, 24 Apr 2026 21:39:39 +0000

When Virat Kohli walks to the crease, traffic on a cricket scoring app doesn't climb gradually — it spikes vertically. One moment you have 5,000 connected users, three minutes later you have 120,000, and every single one wants a push notification on the next ball. That graph broke our first attempt at real-time at Xenotix Labs. Here's what we learned rebuilding it.

The naive stack (don't do this)

Our first iteration: one Node.js process running socket.io, every connected client subscribed to every live match. It worked beautifully at 2,000 concurrent connections. At 15,000 it started dropping heartbeats. At 40,000 the event loop lag crossed 3 seconds and reconnection storms made everything worse.

Lessons from the ashes: a single Node process caps out somewhere between 20k–40k sockets, depending on what else the event loop is doing. Broadcasting to all clients from a single process is O(N) per event — one hot match drives the whole loop. Reconnection storms are real: when you restart a gateway, every disconnected client reconnects within ~2 seconds, a self-inflicted DDoS.

The architecture that held

We rebuilt around three principles. First, WebSocket gateway nodes are dumb and stateless — they only hold connections and forward messages, no business logic. Second, Redis pub/sub is the bus — every gateway subscribes to Redis channels keyed by match_id; score updates are published once and every gateway fans out to its own connections. Third, sticky sessions on the ALB — client reconnects to the same gateway via cookie, so we don't thrash connection state.

The flow: score provider → ingest worker → Redis PUB match:123 → N gateways SUB match:123 → WS push to clients. Scaling is now horizontal: add gateway nodes, Redis fans out. A single Redis cluster handles hundreds of thousands of pub/sub messages per second.

Delta, not snapshots

Every WebSocket message is a delta, not a full state refresh. When a ball is bowled we push {over: 14.3, runs: 4, batsman: "Kohli"}, not the whole scorecard. Why: at 120k connections, a 200-byte delta vs. a 4KB snapshot is the difference between 24 MB/sec and 480 MB/sec of outbound bandwidth per gateway. That changes what instance sizes you need.

Backpressure and slow clients

A real production killer: a mobile client on 2G takes 8 seconds to ACK each message. If you don't handle this, the server buffers pending messages in memory, and eventually that buffer OOMs your Node process. Our rule: if a client hasn't ACKed in 5 seconds, drop the oldest queued messages and send a "resync" event. The client re-fetches the full scorecard from a REST endpoint and resumes the WebSocket. Trades a small UX hiccup for server stability.

Reconnection jitter

When a gateway restarts, add random 0–5 second jitter to the client's reconnect delay. Without it, all N clients reconnect simultaneously and crush the ALB. With it, the load spreads smoothly. On the server side, drain gateways gracefully: ALB stops sending new connections, existing connections finish their current messages, then the process exits. Rolling deploys become a non-event.

Monitoring: three numbers matter

Forget fancy dashboards. Three numbers tell you if real-time is healthy: event loop lag on each gateway (p99 under 50 ms, always), connection count per gateway (under 25k each), Redis pub/sub fan-out latency (time from PUB to last gateway receive, under 100 ms). If any of those drift, rebalance or scale before users notice.

What we'd do differently

Use uWebSockets.js from the start — it's ~5x more efficient than socket.io for raw WebSocket throughput. We migrated mid-project and regretted not doing it day one. Build a load-shedding mechanism earlier: when the system is overloaded, drop low-priority events ("commentary") before high-priority ones ("wicket") — don't treat all messages equally. Test with airplane-mode and 2G emulation — most WebSocket bugs appear during bad-network transitions, not at steady state.

Stack summary

Gateway: Node.js + uWebSockets.js, containerized on ECS
Bus: Redis pub/sub on ElastiCache
Ingestion: Node.js worker, consuming from the score provider
Client: Flutter + Next.js with delta-merge logic
Load balancer: AWS ALB with sticky sessions

Building a real-time product?

Whether it's live sports, collaborative editing, trading platforms, or real-time dashboards — scaling WebSockets is a discipline with sharp edges. If you're building in this space, Xenotix Labs has shipped real-time stacks that survive match-day India traffic. Reach out at https://xenotixlabs.com.

Design Tokens at Scale: Keeping Design Consistent Across 30+ Production Apps

Ujjawal Tyagi — Fri, 24 Apr 2026 21:34:00 +0000

Across 30+ production apps at Xenotix Labs (https://www.xenotixlabs.com) we've used the same design-token pipeline to keep products visually consistent. Different brands, different designers, different platforms, one system. Here is what works.

The problem

Figma designers want to iterate fast. Engineers want a stable contract. If the designer changes a button's hover color and the engineer doesn't know, production breaks. If engineers hardcode colors in their components, the designer loses control of the brand. The only scalable solution is a shared source of truth.

The pipeline

Step 1: designers define tokens in Figma using Variables (scoped by mode: light, dark, brand). Colors, typography, spacing, radii, elevation. Every token has a semantic name (color/primary/500, space/md, radius/sm), never a literal (#3B82F6, 16px).

Step 2: a Figma plugin (we use Tokens Studio) exports the tokens to JSON on commit. The JSON lives in a dedicated git repo (tokens-monorepo) with branches per design system version.

Step 3: Style Dictionary transforms the JSON into platform-specific outputs. For Flutter: Dart constants and a ThemeData extension. For Next.js: Tailwind config and CSS custom properties. For native iOS and Android (when we touch them): .swift and .xml resources.

Step 4: the tokens-monorepo publishes to a private npm registry. Each app installs @xenotix/tokens-{brand}@x.y.z as a dependency. Version bumps flow through dependabot.

What this unlocks

Designers ship brand updates without waiting for engineering. An engineer never has to answer "what color is our primary?" because the answer is always "use the token." Dark mode is free—the same semantic token resolves to different values in dark mode. A/B brand testing is a token-override away.

Where we trip up

Component-level tokens. We learned not to export token names like button/primary/background because the naming explodes and becomes un-maintainable. Instead we keep tokens at the primitive level (color/primary/500) and let component code compose them (button uses color/primary/500 for background, color/neutral/100 for text). This keeps the token count in the low hundreds instead of the low thousands.

Typography is still messy. Figma's text styles don't compose cleanly with programmatic font-weight changes on web. We've settled on shipping 3 font families max per brand (display, body, mono) and letting engineers compose weight + size from primitives. Better than forcing a style token per heading level.

Apps we've shipped this way

Veda Milk D2C subscription platform. Cricket Winner real-time cricket opinion trading. Legal Owl LegalTech super-app with 7 user personas. ClaimsMitra insurance survey platform with 114+ REST APIs. Growara AI WhatsApp automation. 7S Samiti offline-first AI tutor for rural India. Same pipeline, different brands.

About Xenotix Labs

We are a product engineering studio in India building scalable web and mobile platforms for founders. Flutter, Next.js, Node.js on AWS. 30+ products delivered. Figma-to-production in 6 weeks. If you are a founder shipping a product and want design-engineering parity from day one, visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Kafka vs RabbitMQ: When to Use Each (with Real Case Studies)

Ujjawal Tyagi — Fri, 24 Apr 2026 21:31:43 +0000

Message queues are one of those architectural choices where the wrong pick haunts you for years. Pick Kafka when RabbitMQ would have done, and you've bought a 3-node cluster, ZooKeeper (or KRaft) operations, partition management, and consumer group coordination — all to replace what would have been a single RabbitMQ box. Pick RabbitMQ when Kafka was the right call, and you'll spend months migrating when throughput overwhelms you.

At Xenotix Labs we've shipped systems using both. This post is a concrete decision guide, with two case studies from our own work.

The one-sentence summary

RabbitMQ is a message broker. Kafka is a distributed event log. They look similar on the surface, but their internal models are completely different — and that shows up in how you use them.

RabbitMQ model: work queues

RabbitMQ is optimized for task distribution. A producer sends a message, the broker routes it to one of many competing consumers, the consumer acks, and the message is deleted from the queue.

Key properties: messages are consumed once and then gone (no replay), routing is rich (direct/topic/fanout/headers exchanges), priorities work, per-message ack, first-class delayed messages + DLQs + TTLs. This makes RabbitMQ great for work-queue patterns: "process these orders", "send these emails", "resize these images".

Kafka model: partitioned event log

Kafka is optimized for durable, ordered, replayable event streams. A producer appends an event to the end of a partition. Consumers read at their own pace, tracking position via offsets. Messages are never "consumed" — they sit in the log until retention expires.

Key properties: events are retained (rewind offsets and reprocess), ordering is per-partition, throughput is enormous (hundreds of thousands of events/sec on modest hardware), consumers are independent, partition keys matter (design once, hard to change later). This makes Kafka great for event-sourcing: "every trade", "every user interaction", "everything that happened in the system".

Case study 1: Veda Milk — RabbitMQ

Veda Milk is our D2C dairy subscription platform. Every night at 10 p.m., the system generates tomorrow's orders for every active subscriber. Classic work-queue.

Why RabbitMQ: each message represents work that must succeed exactly once — ack-on-success, nack-on-failure, DLQ for retries. We don't need replay; if an order failed, the fix is manual retry, not replaying a week of events. Throughput is low (~100k messages per night — a rounding error for RabbitMQ). Delayed messages matter for wallet-low reminders. One RabbitMQ instance on Amazon MQ runs the whole thing.

Case study 2: Cricket Winner — Kafka

Cricket Winner is our real-time cricket platform with live scores, news feeds, and opinion trading. Every trade is an event published to the trades topic, partitioned by market_id. Multiple consumers — matching engine, pricing, settlement, personalization — read the same events.

Why Kafka: multiple consumers need the same events. Replay matters — when we found a matching-engine bug, we rewound the partition offset and reprocessed. Throughput is high (~50,000 trades/minute on match days). Partitioning on market_id gives per-market ordering and cross-market parallelism simultaneously. Three-broker MSK cluster holds under match-day load.

Decision checklist

Ask these in order:

Do consumers need to replay events? Yes → Kafka.
Do multiple independent systems need the same events? Yes → Kafka.
Consistently exceeding 10,000 messages/second? Yes → Kafka.
Need rich routing, priorities, delays, DLQs out of the box? Yes → RabbitMQ.
Otherwise → RabbitMQ is almost always simpler to operate.

Common mistakes

Picking Kafka for a classic work queue — you'll end up implementing DLQ, priorities, and delays by hand, badly. Picking RabbitMQ for event sourcing — you lose history the moment a consumer acks. Running Kafka without a real ops plan (monitor ISR, disk, partition lag). Mixing the two without clear boundaries (it's fine to use both — we do — but draw the line: Kafka for events, RabbitMQ for tasks).

Need help designing your messaging layer?

Picking the right message broker is cheap to get right at day zero and brutally expensive to fix at year two. If you're architecting a real-time system, event-driven platform, or high-throughput commerce stack, Xenotix Labs has shipped the full spectrum — from subscription commerce on RabbitMQ to real-time trading on Kafka. Reach out at https://xenotixlabs.com.

Architecture of ClaimsMitra: 114+ REST APIs for Insurance Survey Platform

Ujjawal Tyagi — Fri, 24 Apr 2026 21:24:50 +0000

Insurance in India runs on surveys. When a claim comes in—a car accident, a flooded basement, a health emergency—a surveyor physically visits the site, inspects the damage, documents it with photos and reports, and submits the assessment back to the insurer. The turnaround used to be 5–10 days. One of our clients at Xenotix Labs (https://www.xenotixlabs.com) wanted to get it to under 24 hours.

The result was ClaimsMitra—a mobile + web platform connecting insurers, surveyors, hospitals, garages, and claimants on one pipeline. We shipped 114+ REST APIs across 8 microservices, MySQL for core state, and a Flutter app that works offline for field surveyors in patchy network areas.

The domain complexity

Insurance is not one workflow. It's dozens. Motor claims flow differently from health claims from property claims from marine. Each has its own document requirements, approval hierarchies, fraud checks, and settlement paths. The first architectural decision was to avoid the "one giant workflow engine" trap. Instead we built per-domain state machines that share a common audit-log infrastructure but have independent business logic.

The 114 REST APIs

People ask why so many APIs. Insurance platforms have massive surface area: user types (surveyor, insurer, claimant, garage, hospital admin, agent), entity types (claim, policy, vehicle, document, estimate, settlement), lifecycle events (report, assign, inspect, estimate, approve, settle, reopen), and integrations (Razorpay for payouts, Aadhar OTP for KYC, multiple insurer APIs). 114 endpoints across 8 services turns out to be lean for the domain.

We grouped the services by bounded context: claims-core, surveyor-ops, document-vault, estimation-engine, settlement, notifications, analytics, admin. Each service owns its database tables and exposes APIs with contract versioning via URL prefix (/v1/, /v2/). Services talk to each other via HTTP for synchronous needs and RabbitMQ for async events.

Offline-first Flutter for surveyors

Surveyors work in places without network. We built the mobile app to capture photos, geotag, audio notes, and inspection reports fully offline, then sync when back online. Photos are stored locally, compressed to 200KB each, and queued for S3 upload. Inspection reports are structured JSON with a local SQLite store (Drift ORM). Sync reconciliation uses vector clocks to handle conflicts when the surveyor edits on two devices.

Document handling

114 APIs implies a lot of documents. We use S3 with presigned URLs for upload (no bytes go through our backend), virus-scan via ClamAV in a Lambda trigger, and persist metadata (hash, uploader, claim_id, visibility) in MySQL. PDFs get OCR'd via Textract for searchability.

Results

Median claim settlement time went from 7 days to 18 hours. Surveyor productivity 2.3x (fewer callbacks because of better first-visit capture). Fraud-reject rate up by 12% (better data means better detection).

About Xenotix Labs

We're a product engineering studio in India. 30+ products shipped including Veda Milk (D2C dairy), Cricket Winner (real-time cricket on Kafka + WebSockets), Legal Owl (LegalTech super-app), Growara (AI WhatsApp automation), and 7S Samiti (offline AI tutor for rural India). Flutter, Next.js, Node.js on AWS. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Building Offline-First Mobile Apps for Emerging Markets with Flutter

Ujjawal Tyagi — Fri, 24 Apr 2026 21:19:38 +0000

Real-Time Cricket at Scale: The Architecture Behind a Live Scoring + Opinion Trading Platform

Ujjawal Tyagi — Fri, 24 Apr 2026 21:11:17 +0000

webdev, architecture, node, kafkaIndia consumes cricket like no other country on earth. When Kohli walks out to bat, millions of users hit refresh simultaneously. When a wicket falls, chat rooms explode. When an opinion-trading market opens on the next ball, orders pour in at rates you'd expect from a small stock exchange.

Building a platform that holds up under that load — and makes money from it — is an interesting engineering problem. Here's how we built Cricket Winner at Xenotix Labs, a real-time cricket intelligence platform with live scores, news, and opinion trading in one app.

Three user experiences, one platform

Cricket Winner isn't a single product. It's three products glued together:

Live score engine — ball-by-ball updates synced within seconds of the actual ball being bowled
News feed — minute-by-minute cricket news and editorial content, personalized per user
Opinion trading — a prediction market where users buy and sell "yes/no" contracts on cricket outcomes

Each subsystem has wildly different engineering constraints. The trick was building a shared backbone that doesn't compromise any of them.

The fan-out problem

When a ball is bowled and the score changes, every active user needs to know — within 1–2 seconds. We're talking hundreds of thousands of concurrent connections during a peak match.

Polling is out (wasteful, laggy, and kills battery life on mobile). Server-Sent Events are good but one-way. We went with WebSockets backed by a Redis pub/sub layer.

The flow: data ingestion worker pulls from our score provider's feed. Every score delta is published to a Redis channel keyed by match_id. A cluster of WebSocket gateway nodes subscribe to Redis and fan out to connected clients. Clients get a delta, not a full state refresh (saves bandwidth).

Horizontal scaling is easy: add more gateway nodes behind an ALB, and Redis pub/sub takes care of distributing messages.

Why Kafka (not RabbitMQ) for trading and news events

For opinion trading, the throughput and event-replay requirements are very different. Every trade, every order-book update, every price recalculation is an event that needs to be durable and replayable.

Kafka is a better fit here because:

High throughput — Kafka handles millions of messages per second on modest hardware
Replay — we can rewind and reprocess events (useful for rebuilding order books after bugs)
Partitioning — we partition by market_id, so each market's events are totally ordered and processed by a single consumer

The news pipeline uses the same Kafka cluster for a different reason: personalization. Every user interaction (read, skip, like, share) is a Kafka event. A ranking worker consumes these events and updates per-user feed ranking in near real time.

Why MongoDB for the data layer

Most Xenotix Labs projects default to PostgreSQL. Cricket Winner was the exception.

Ball-by-ball match data is deeply nested. An over has 6 balls. Each ball has a batsman, bowler, runs, extras, a commentary string, and sometimes wicket details. Storing that as JSON documents is a natural fit. Schema evolution is constant — new stats, new tournament formats, new commentary types — and MongoDB's flexible schema lets us ship new features without migrations. Read patterns favor document stores: the most common query is "give me everything about this match" — one document fetch vs. six joins in a relational DB.

For the wallet and trading ledger, we kept things stricter: a separate PostgreSQL database with strong ACID guarantees. Money never lives in MongoDB.

The opinion trading engine

This was the hardest part to build. An opinion-trading market works like this: a market opens ("Will India win the toss?"), users buy YES at ₹3 or NO at ₹7 (prices sum to ₹10), as opinion shifts the price shifts, and when the event resolves YES holders get ₹10 each.

The matching engine is a single-threaded Node.js worker per market partition (Kafka guarantees per-partition ordering). Running single-threaded avoids race conditions; partitioning by market_id avoids the worker becoming a bottleneck.

10 each.

Behind the scenes: each market has an order book (limit orders on both sides). A matching engine pairs buyers with sellers at crossing prices. Settled orders update user wallets atomically. Market prices flow back to the client via WebSocket for live UX. The matching engine is a single-threaded Node.js worker per market partition (Kafka guarantees per-partition ordering). Running single-threaded avoids race conditions; partitioning by market_id avoids the worker becoming a bottleneck.

Tech stack summary

Mobile: Flutter (iOS + Android)
Web: Next.js
Backend: Node.js + MongoDB (+ PostgreSQL for money)
Real-time: WebSockets + Redis pub/sub
Event backbone: Kafka
Architecture: Microservices
Deployment: AWS

What we'd do differently

Put the WebSocket gateway behind a dedicated load balancer early
Start with Kafka from day one instead of migrating mid-project
Cache the order book in Redis for fast recovery after worker restarts

Building a real-time product?

Whether it's live sports, collaborative tools, or trading platforms — real-time is a discipline. If you're building something in this space, Xenotix Labs has the stack and the scars. Get in touch at https://xenotixlabs.com.

From Figma to Production in 6 Weeks: Our MVP Playbook for Founders

Ujjawal Tyagi — Fri, 24 Apr 2026 21:04:29 +0000

Every founder asks the same question: can you ship my MVP in 6 weeks? At Xenotix Labs (https://www.xenotixlabs.com) we've shipped 30+ products across D2C, edtech, fintech, healthtech, SaaS, and marketplaces. This is the playbook we actually use when the answer is yes.

Week 0: the pre-work you can't skip

Ninety percent of MVPs that slip do so because week 0 was compressed. We block a hard 3-day pre-sprint before we touch code. Three outputs: a clickable Figma prototype of the happy path (not every screen—just the demo flow a founder would show an investor), a data model sketch on paper or Miro, and a one-page "what this MVP does not do" list. The last one is the most important. Founders change their minds three times in week 2; we show them the don't-do list and ask "still?"

Weeks 1–2: the vertical slice

We do a thin vertical slice first: one flow from UI to DB and back. For a Flutter app that's usually "sign up, see home, tap one card, see detail, go back." For a Next.js web product it's the login plus dashboard shell. Why: this forces every infrastructure decision up front. Auth. State management. API contract. DB migrations. Deployment pipeline. If any of these wobble, we'd rather find out in week 1 than week 5.

Our default stack for this slice: Flutter with Riverpod for mobile, Next.js with App Router for web, Node.js with Fastify on the backend, PostgreSQL with Prisma for data, Clerk or custom JWT for auth, and a single GitHub Actions workflow deploying to AWS (ECS Fargate for backend, S3+CloudFront for web, app stores for Flutter). This stack has gotten us to production in under 3 weeks when everything breaks right.

Weeks 3–4: horizontal fill-in

With the slice proven, we add screens and endpoints in parallel. This is the part that looks most like a sprint. Two rules: every PR merges behind a feature flag, and every endpoint ships with one happy-path Playwright test. Feature flags mean we can demo the product weekly without waiting for everything to be perfect. Tests mean we don't regress fundamentals while velocity is high.

Design handoff: we don't wait for final pixel-perfect designs. We build to a working palette and spacing system (Tailwind on web, custom ThemeData on Flutter) and swap in final assets in week 5 when Figma is locked. Founders worry about this but it saves 10-15 days.

Week 5: the ugly week

Bugs. Payment integration. Email templates. Edge cases you forgot existed. OAuth flows with Apple that break because of a subdomain typo. This week exists in every MVP we ship. Plan for it.

Our trick: we hold a 48-hour "bug bash" where one engineer dogfoods the app as a non-technical user for two straight days and files every annoyance. We fix the top-voted ones. The bottom half get deferred to post-launch.

Week 6: ship

We hard-lock scope on Monday of week 6. Tuesday is the release candidate. Wednesday is stakeholder demo. Thursday is prod deployment. Friday is monitoring. We've never missed a launch when the founder let us hold the scope lock.

What breaks the 6-week timeline

Three things, in order of frequency. (1) Scope creep disguised as "just one more screen." (2) Founder co-builds with us in week 4 instead of decision-making; this doubles every step. (3) Third-party integrations that we didn't identify in week 0 (payment gateways in emerging markets, KYC APIs with async approvals, WhatsApp Business API onboarding queues).

Products we've shipped this way

Veda Milk: D2C dairy subscription platform (Country Delight clone) on Flutter + Next.js + Node.js + RabbitMQ. Cricket Winner: real-time cricket scoring plus opinion trading on Kafka + WebSockets. Legal Owl: LegalTech super-app with 7 user personas and live lawyer video calls. Growara: AI WhatsApp automation on Meta Business API plus LLM. 7S Samiti: offline-first AI tutor for rural India. ClaimsMitra: insurance survey platform with 114+ REST APIs.

Hiring us

If you're a founder with an MVP to ship, we'd love to talk. We're a team of full-stack engineers from NITs and IITs building end-to-end from Figma to production. Flutter, Next.js, Node.js on AWS. Visit https://www.xenotixlabs.com or email leadgeneration@xenotix.co.in.

Building LLMs for Bharat: What 6 Months of Rural AI Deployment Taught Us

Ujjawal Tyagi — Fri, 24 Apr 2026 10:55:37 +0000

Most coverage of "AI for India" treats the subject the way Silicon Valley treats emerging markets — translate the product, localize the UI, and you're done. Six months of production deployment of 7S Samiti, our AI tutor for rural Indian students, has taught us that this framing is almost completely wrong.

This is a piece about what we actually learned building an LLM-powered education product for students in low-connectivity, low-literacy-adjacent environments in rural India. It's not a case study about an AI that worked. It's a case study about the specific, surprising ways it broke, and what we did about it.

The Problem We Were Solving

7S Samiti is a mission-driven edtech platform. The goal: deliver personalized, adaptive learning to rural Indian students at a price point that doesn't exclude them. The stack:

Mobile app (Flutter, offline-first) deployed to entry-level Android phones.
AI tutor that generates quizzes, assignments, and study notes on demand, in the student's preferred language.
Local caching + selective sync for areas with 2G-only connectivity.
Parent/teacher dashboard for progress tracking.

We deployed to pilot schools in three states (Uttar Pradesh, Maharashtra, Rajasthan). 2,400 students in the initial rollout.

Failure #1: The Tokenization Problem

Every multilingual LLM paper talks about "parameter efficiency across languages." What they don't talk about: Hindi and Marathi have 2-4x worse tokenization efficiency than English in most off-the-shelf models.

A 200-word Hindi paragraph eats ~600 tokens where the English equivalent eats ~150. Latency is higher. Cost is higher. Quality of generation is often lower because you're burning context budget on writing the same content.

Three fixes that worked:

1. Route by language. English queries to GPT-4. Hindi/Marathi queries through a dedicated pathway with tokenizer-aware prompts.

2. Translate-generate-translate for complex content. For long-form study notes, we generate in English and translate to Hindi/Marathi as a post-process. Three model calls instead of one. Surprisingly produces higher-quality Hindi than direct generation, because the model's reasoning in English is stronger.

3. Pre-generate common content. 80% of what students request is predictable. We batch-generate overnight, cache it, and serve from cache for 90% of requests.

Result: latency dropped from ~4s to ~800ms for cached content. API cost dropped by 70%.

Failure #2: Voice vs. Text

Our initial app was text-first. Deployment showed us: rural Indian students use voice input 8x more often than text.

Many students are the first generation in their family learning to read and write fluently in their regional language. Typing in Devanagari or Marathi script on a tiny phone keyboard is slow and intimidating. Speaking is natural.

What we did:

Voice input became the default UX. App usage doubled within two weeks.
Audio output for all AI responses. Students listen 3x longer than they read.
Multimodal interaction for math. Students photo a math problem, we OCR + solve + explain by voice. Drove 40% of daily active usage in month one.

Failure #3: Connectivity Reality

We designed for "low bandwidth." Reality: students use the app during a 15-minute window when they have signal, then go offline for hours.

The naive implementation — real-time cloud LLM calls — doesn't work. Students tap "solve," wait 8 seconds, then lose signal mid-request.

What we shipped:

Queue-and-sync model. Students ask questions offline. App queues, syncs when signal arrives, pushes responses back.
On-device inference for basic queries. Distilled quantized model (~4B params) runs locally for ~30% of common requests. Zero connectivity required.
Selective sync with priority. Prioritize unanswered questions > content updates > analytics when the 15-minute window arrives.

Impact: session completion rate went from 34% to 88%.

Failure #4: What the AI Didn't Know About Students

First prompts were generic. Output was technically correct but culturally irrelevant. We'd explain algebra using apples and oranges to a student who'd never seen an orange. Chemistry with lab metaphors to students who'd never seen a Bunsen burner.

Fixed at the prompt layer:

Regional context injection. Every prompt includes the student's state, language, and region-appropriate analogies.
Textbook alignment. State boards use different textbooks. We pre-ingested Maharashtra Board, CBSE, UP Board syllabi.
Humility prompts. "If outside the standard textbook for the grade, say so and offer the closest related question." Reduced confidently-wrong answers by 80%.

Deployment Data

After 6 months in production:

2,400 students across 3 states.
~38K AI interactions per day at peak (mid-exam season).
~₹0.02 per interaction (after optimization).
Session completion rate: 88% (up from 34% at launch).
Voice input share: 76% of total queries.
Cached content hit rate: 89% during exam-prep weeks.

Monthly AI-serving cost per student: ~₹285. Target price ₹99/month. We lose money today but the trajectory works once we hit 10K+ students.

Five Lessons

Vernacular LLMs are a tokenization problem before they're a model problem. Fix tokens + prompts before picking a model.
Voice-first changes everything. If building for rural India, voice IS the interface.
Design for bursty connectivity. 15-minute-window sessions are the real use case.
Cultural context in prompts is not optional. Analogies matter more than raw model quality.
On-device + cloud hybrid is the only viable architecture. Neither alone works.

Where This Goes

Building AI for Bharat is not a translation problem. It's a systems problem involving tokenization, connectivity, UX modality, and cultural context — all of which need to be solved in concert.

At Xenotix Labs we've shipped 7S Samiti + Growara (WhatsApp AI automation) + Alcedo (AI-powered education discovery) — three different LLM-powered products for Indian users. Each taught us something that contradicted what the AI literature said would happen. If you're building AI solutions for startups in the Indian context, these failure modes are probably in your future. Getting ahead of them saves months.

Ujjawal Tyagi is the founder of Xenotix Labs, a product engineering studio that's shipped 30+ production apps including 7S Samiti (AI tutor for rural India), Growara (AI WhatsApp automation), and Cricket Winner (real-time cricket trading).

What It Actually Takes to Build AI WhatsApp Automation for Indian SMBs (Lessons From Growara)

Ujjawal Tyagi — Fri, 24 Apr 2026 10:42:36 +0000

Every Indian founder I've met in the last two years has the same WhatsApp problem. Customers DM them at all hours. Half the queries are the same five questions. The founder ends up being the company's unpaid, always-on customer support. At 50 customers a day it's manageable. At 500 it breaks the business.

We built Growara to solve this. It's an AI-powered WhatsApp automation platform — businesses plug it into their WhatsApp Business account and the AI handles FAQs, books appointments, escalates complex queries to humans, and goes quiet when it should. Sounds simple. Wasn't.

This piece is about what actually broke when we shipped it to Indian SMBs, the decisions that worked, and the ones we'd revisit.

The Lazy Assumption Everyone Makes

Before we started, every article I read about "AI WhatsApp bots" treated the problem as solved: "Just plug GPT into the WhatsApp Business API." I believed that for about two weeks.

Three things break that premise when you ship to real Indian SMBs:

1. Language. Indian customers don't chat in clean English. They chat in Hinglish — "bhai price kitne ka hai?" — or in full Hindi, Marathi, Tamil, or Gujarati, often in Roman script. Off-the-shelf LLMs handle English beautifully and Hinglish surprisingly well, but regional-language-in-Roman-script is a minefield. "Kya" is Hindi for "what," but depending on context the model sometimes reads it as a name.

2. WhatsApp's 24-hour window. WhatsApp Business API has a hard rule: after 24 hours of silence from the customer, you cannot message them first unless you use an approved template. Your bot CANNOT just "follow up tomorrow" without pre-registering a template with Meta and paying per-template fees. This one rule shaped half our architecture.

3. The "human handoff" edge case. The hardest question in any AI support system isn't "can the AI answer?" It's "how does the AI know when it can't?" Getting this wrong means either (a) an AI that gives confidently wrong answers, or (b) an AI that escalates everything and adds no value.

Our Actual Architecture

[WhatsApp user message]
     | (Meta Business API webhook)
[Node.js Gateway]
     |
[Message Classifier — small fine-tuned model]
     | branches to:
  |-- [Template Response] — for repeated FAQs (cached)
  |-- [LLM Response] — for freeform queries
  +-- [Human Handoff Queue] — for complex/ambiguous
     |
[WhatsApp Business API reply]

The classifier matters more than the LLM. Most queries — "What are your prices?" "Where are you located?" "When do you open?" — don't need an LLM at all. A small fine-tuned classifier (we use a distilled version of a multilingual BERT) catches them and returns a pre-written, founder-approved answer. Latency: 80ms. Cost: effectively zero. This handles about 65% of real message volume.

The LLM is only called for the hard 35%. When the classifier isn't confident, we go to the LLM with a heavily engineered prompt that includes business context, recent conversation history, and explicit escalation criteria.

The human handoff queue is the safety net. When the LLM's output is below a confidence threshold OR when certain red-flag keywords fire (price negotiation, complaint, payment issue), the message goes to a dashboard where the business owner replies from their browser. The AI never fakes confidence it doesn't have.

The Hinglish Problem, Solved

Our most-hated bug in the early weeks was the classifier confidently labeling "mujhe price batao bhai" as an appointment-booking request because the word "batao" appeared in some appointment training data.

What worked:

1. Fine-tune on real data, not synthetic. We bootstrapped with a few thousand messages from our own WhatsApp Business pilots. The gap between synthetic and real Hinglish was humbling.

2. Add a translation pass for the LLM. For the 35% that goes to the LLM, we first translate Hinglish/Marathi/Tamil into English using a small dedicated model, prompt GPT in English, then translate the response back. Three model calls instead of one. Latency bump ~600ms. Accuracy jump ~22 percentage points. Worth it.

3. Per-vendor terminology list. Each vendor onboards with a 20-term glossary (product names, service names, industry jargon) that gets prepended to every LLM prompt. Vendor-specific context beats bigger models.

The Handoff Threshold That Actually Works

The single highest-impact tuning decision we made: we set the LLM confidence threshold for human handoff aggressively high — meaning the AI hands off more readily than most teams would.

Counterintuitive? Yes. Customers would rather talk to a human than a wrong AI. Vendor satisfaction jumped when we reduced the AI's eagerness to answer edge cases. We also added four hard-coded handoff triggers:

Any message containing "refund", "complaint", "problem", "issue", or their Hindi equivalents.
Any numeric question about price >₹500 — our vendors' margins require human negotiation.
Any message after a previous human handoff in the same conversation.
Any message from a customer flagged as VIP.

These four rules alone improved our Net Promoter Score for the automation by 18 points.

What the Math Looks Like

For a typical vendor processing 500 WhatsApp messages per day:

65% handled by classifier alone: ~325 messages, near-zero marginal cost
25% handled by LLM after classifier miss: ~125 messages, ~₹3.50 per message
10% escalated to human: ~50 messages, vendor's own time

Monthly infrastructure cost per vendor: ₹3,000–5,000. Monthly LLM API cost: ₹13,000–15,000. We charge ₹25,000/month. The economics work because the classifier absorbs most volume.

Without the classifier — if we sent every message to GPT — cost per vendor would be ~₹45,000/month and the product wouldn't exist.

Five Lessons Compressed

The AI is never the hard part. The WhatsApp Business API, the language edge cases, and the handoff UX consumed 80% of engineering time.
Small models beat big models on tight-context tasks. A fine-tuned classifier for intent routing is cheaper, faster, and more accurate than calling GPT-4 for every message.
Hinglish needs real data. Synthetic training sets lie to you. Pay to collect real conversation logs from pilot vendors before shipping.
Design for the 24-hour window from day one. Templates aren't an afterthought — they're a core data model.
Hand off more, not less. Customers forgive a human-in-the-loop AI. They don't forgive a confidently wrong AI.

Taking the Leap

If you're an Indian SMB tech team thinking about building something similar, the path is real but narrower than the marketing suggests. You need a ruthless focus on the top 20 FAQs your customers actually send, real conversation data before you train anything, an explicit human-handoff UX that your vendors actually want to use, a template library per vendor registered with Meta, and a classifier-first architecture where LLMs are the expensive exception, not the default.

At Xenotix Labs we've built this stack — Growara is one of several AI solutions for startups we've shipped. If you're exploring WhatsApp automation as part of your product roadmap or looking at MVP development services for startups, the patterns above apply whether you build with us or roll it yourself.

AI WhatsApp bots are a real product category in India. The teams that win are the ones honest about where the AI stops working.

Ujjawal Tyagi is the founder of Xenotix Labs, a product engineering studio that's shipped 30+ production apps including Growara (AI WhatsApp), Cricket Winner (real-time cricket trading), and 7S Samiti (AI tutor for rural India).