Internal reporting of product features and issues helps identify opportunities to improve the end-user experience.Analysing these issues often requires checking different systems: bookings, payments, wallets, and notification logs. Doing this manually is tedious.

Hence we decided to leverage AI to fast track the process .

During the similar time frame there were MCPs being built for internal systems for other use cases. We decided to leverage the same as phase 1 and thus the idea of Bug Triagence (Triage + Intelligence) was born.

An example

Consider a standard customer report:

“I cancelled my ticket Txxxxx9 yesterday. The cancellation went through, but I never got a refund notification. Can you check?”

To triage this, an engineer or support agent has to manually verify:

• Was the booking actually cancelled in the booking database?
• Did the payment service generate a refund record?
• Is the money sitting in pending, completed, or failed state?
• Did the notification service attempt to send an email/SMS, or did the trigger fail?

This would take considerable time if the data lives in different tools and databases.

What We Wanted “Bug Triagence” to Do

Read an issue → check the right systems → write clear findings on the ticket, with proof.

We wanted it to:

• Save time — Check several systems at the same time
• Stay honest — Use real data; if proof is missing, say so
• Stay clear — Each agent writes what it found and from where
• Grow over time — Add a new agent for a new system without rewriting everything
• Keep working if AI is down — Also support a simpler “rules in code” mode

System architecture

Using our simple case:

“I cancelled my ticket. Cancellation worked. I did not get a refund notification.”

Below is the workflow

• Issue is reported
• Read the text and pull out IDs and dates
• Decide which agents are needed (booking, payments, wallet, notifications)
• Run those agents at the same time
• Each agent loads a short written playbook, may call tools a limited number of times, and posts what it found + where it came from. If one agent fails, the others still finish.
• Each agent writes its own comment with sources
• Coordinator writes one short summary on top
• Save a record for later review

Design rules

Rule 1: Agents operate independently.

We don’t chain agents sequentially where Agent A blocks Agent B. A central coordinator extracts initial parameters and fires off domain-specific Agents simultaneously. If the notification service is down, the payment and booking checks still finish and post their findings.

Rule 2: Facts before narrative.

We gather evidence first , then ask the AI to explain it.

Order of work:

• Pull IDs from the text (order id, booking id, email, etc.) using simple parsing where we can
• Fetch starter data from systems
• Let the AI ask for more data only when needed, with a max number of tries
• Write the explanation using rules we already wrote down

If we cannot find a useful ID, we stop and say so. We do not invent one.

Rule 3: Version-controlled playbooks.

Investigation steps shouldn’t live inside massive system prompts or human heads. We maintain short markdown guides per domain detailing what tools to call, what data to verify, and what claims are strictly forbidden without proof.

When the process changes, we update the guides. The agents load it when they run.

An Investigation Walkthrough

Using our example case (“Cancelled booking BK-10234, missing refund notification”):

1. Extraction: Coordinator parses BK-10234 and identifies the intent.
2. Parallel Dispatch: Four specialized agents run at the same time using shared initial context.

• Booking Helper: Queries booking API > Confirms status is CANCELLED at 18:12 UTC.
• Payments Helper: Queries ledger > Confirms refund RF-8821 was issued successfully.
• Notification Helper: Queries log store > Finds refund_issued event was never produced by the message bus.

3. Sourced Output: Each helper leaves a short comment on the internal ticket with direct links/IDs. The coordinator posts a top-level summary

4. Investigation Summary:

• Booking: Confirmed cancelled (BK-10234 at 18:12 UTC).
• Payment: Refund processed successfully (Ref: RF-8821).
• Notification: Issue identified. Event refund_issued failed to emit from message queue.
• Action Needed: Engineering review on notification queue consumer.

Risks we faced and Mitigated

Integrating autonomous AI agents into internal workflows carries real production risks, from data exposure and hallucinated claims to runaway API costs. To keep the triage system secure, reliable, and cost-effective, we established strict operational guardrails right at the architecture level.

What improved

Automating our triage workflow delivered below gains

• Faster first look at multi-system tickets
• More consistent checks across issues
• Clearer handoff notes for engineers
• Easier onboarding of a new check area via a new playbook

Bug Triagence was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why Traditional Test Frameworks Fall Short

Modern applications are no longer just REST endpoints and web pages. A single user query today might traverse:

• A WebSocket stream carrying incremental tokens
• A gRPC call between microservices
• A Server-Sent Events (SSE) channel pushing agent updates
• An Agent-to-Agent (A2A) protocol coordinating specialized reasoning agents
• One or more LLM invocations, each with its own latency, cost, and correctness profile
• A UI that stitches all of the above into a coherent experience

Testing agentic AI is not a single problem; it is a stack of them. A modular framework is the only shape that keeps pace as the stack grows.

Testing this stack with a single tool — Postman for APIs, JMeter for load, Selenium for UI — quickly becomes unmanageable. Reports live in silos. Regressions in one layer surface only in production. Semantic correctness (did the agent actually answer the user’s question?) is left entirely to manual QA.

This article walks through the architecture of a modular, multi-protocol regression automation framework designed for agentic AI systems, and the principles that keep it maintainable as new protocols and models appear.

The Bug Status Codes Never Catch

A release that looked green in CI shipped a subtle agent regression. The user asked a travel-search agent for buses with sleeper berths on a given route. The WebSocket returned 200, tokens streamed, and the UI rendered a polished reply recommending buses — none of which had sleeper inventory for that night.

What went wrong?

• The coordinator skipped the inventory specialist and answered from prior turn context
• Structural API checks still passed — a message was returned
• Exact-string asserts were useless: the reply was fluent, helpful-sounding, and wrong
• Manual QA had covered the happy path the day before; this edge phrasing was new

A modular agentic framework catches this class of bug by layering validators the status code cannot see:

1. Agent-flow — expected specialist agents (and tools) must appear in the execution trace
2. State — required keys (route, date, filter dimensions) must be populated
3. Semantic — a judge scores faithfulness and relevance against the user intent and ground truth
4. Integration — the same case can be replayed from UI or voice to confirm the UX surface agrees

The rest of this article is the architecture that makes those four checks routine instead of heroic.

Core Design Principles

Before writing a single line of code, pin down the principles that will govern every module.

1. Modularity over monolith. Each testing concern — WebSocket load, backend flow, UI journey, LLM benchmarking — lives in its own module with its own lifecycle. New protocols slot in as siblings, not as forks.
2. Shared core, isolated execution. A single core module owns configuration, models, logging, and reporting. Everything else depends on it and nothing else.
3. Data-driven test cases. Tests are defined in YAML/JSON, not baked into Java classes. QA engineers add coverage without touching framework code.
4. Semantic assertions are first-class. For agentic systems, “the endpoint returned 200” is not a passing test. The framework must reason about whether the answer was correct.
5. One dashboard to rule them all. Every module publishes to a common results store so a single UI shows the health of the entire stack.

The Module Layout

Each module is an independent Maven (or Gradle) project. The parent POM enforces shared versions of Java, JUnit, Allure, Lombok, and Jackson so drift never becomes a debugging tax.

Module Deep Dive

1. Core: The Backbone

The core module is intentionally boring — and that is the point. It exposes:

• TestConfig — a singleton config loader that reads a single YAML and exposes typed getters
• JsonUtils / YamlUtils — serialization helpers with sensible defaults
• Base result models (TestResult, TestRun, Metric) shared by every module
• A pluggable reporter interface so results can be pushed to a database, a file, or a message queue

Rule of thumb: if you find yourself copying a utility between two modules, it belongs in core.

2. WebSocket: Streams Under Load

WebSocket testing has two flavors — functional (does the stream emit the right events in the right order?) and load (how many concurrent streams can the server sustain?). A well-designed module handles both with the same primitives:

• A WebSocketTestClient that opens a connection, sends a payload, and collects an event stream
• A LoadExecutor that spins up N clients on a thread pool and aggregates metrics
• A metrics collector that captures latency percentiles, throughput, error rates, and connection lifecycle events

The load executor scales from 10 to 1000+ connections with a single config change.

3. Backend: Validating Agent Flows

For an agentic system, “backend testing” means more than hitting endpoints. You need to assert that:

• The right agents were invoked
• They were invoked in the right order (or in an acceptable partial order for flexible flows)
• The shared state was populated with the expected keys
• The final response satisfies domain rules

A clean approach uses a YAML schema per test case:

The framework parses each case, executes it against the target system (via WebSocket or HTTP), and runs four validators in sequence: agent-set, execution-order, state, and response.

One Query, End to End

Architecture diagrams convince architects. A single case walking the pipeline convinces everyone else. Here is the sleeper-bus query as a full run:

1. YAML defines intent — the case above: query, expected agents, state keys, semantic thresholds.

2. Executor opens the real channel — typically WebSocket. The client sends the user query and collects the event stream until the final payload arrives (or a timeout fires).

3. Structural validators run first (cheap, deterministic):

At this point the run already fails — without spending a judge-LLM call. That ordering matters for cost.

4. Semantic validation runs when structure passes (or always, if you want audit evidence on known failures). A typical TestResult payload looks like:

5. Dashboard + Allure ingest the same record. A week later you can ask: every failure for sleeper/inventory flows across WebSocket and UI in the last 7 days — because every result is tagged with module, protocol, and scores.

That one case is the contract between QA (who owns YAML), backend (who owns agent traces), and ML (who tunes judge thresholds).

4. Frontend: E2E With Discipline

UI tests earn their reputation for flakiness when Page Object Model discipline is skipped. Enforce it:

• One page class per screen, exposing intent-level methods (e.g. submitForm(input)), never raw selectors
• A WebDriverFactory that produces headless-or-headed drivers based on config
• Screenshot-on-failure baked into the base test class
• Explicit waits everywhere; implicit waits nowhere

5. LLM: Benchmarking Beyond Latency

The LLM module is where most frameworks quietly give up. Don’t. Structure it around three orthogonal dimensions:

• Performance — latency, tokens per second, cost per response
• Quality — correctness, relevance, completeness (scored via a judge model or rubric)
• Consistency — variance across N runs of the same prompt

A BenchmarkOrchestrator runs the same prompt suite across multiple models, and a Comparator produces a leaderboard. When a new model releases, you swap one line of config to see whether it beats the incumbent.

6. Protocol Modules: gRPC, SSE, A2A

Each protocol gets its own module because each has a different failure mode. gRPC needs schema/proto management. SSE needs long-lived connection handling and reconnect semantics. A2A needs delegation-tree validation. Sharing a core ProtocolTestClient interface lets integration tests treat them uniformly.

7. Semantic: The Assertion Layer for AI

Traditional assertions (assertEquals(200, response.status)) fail silently on the questions that matter. Agentic outputs are non-deterministic: two correct runs may phrase the same answer differently, so exact-string matching produces either perpetual flakes or permanently weak tests.

The semantic module treats scoring as a first-class assertion API every other module can call the same way it calls assertEquals.

Three assertion tiers (use the cheapest that works)

1. Structural — required fields, enums, IDs, shapes. Deterministic. Prefer this for catalog IDs, filter dimensions, and status codes.
2. Embedding similarity — cosine distance to a reference answer. Fast and cheap; good for paraphrase tolerance when the gold answer is stable.
3. Judge-LLM / rubric — pass response + expectation (+ optional ground truth) to a judge model; get scores, a verdict, and a written justification. Use when meaning matters more than wording.

Configure pass thresholds per scenario (e.g. faithfulness ≥ 0.75), not globally. A FAQ bot and a transactional booking agent do not share the same bar.

When not to use a judge

• Structured fields you can assert exactly (IDs, codes, counts against inventory)
• High-volume suites where judge cost would dominate CI (gate with structure first; sample for judge)
• Cases where the judge itself is under-calibrated — two judge disagreements on the same case is a signal to fix the rubric, not to lower the threshold blindly

Keeping semantic tests from going flaky

• Prefer must-contain topics / must-not phrases alongside continuous scores
• Run the judge after structural checks so you fail fast on missing agents
• Track judge cost and disagreement rate on the dashboard; spike = prompt or model drift
• Allow a pluggable judge backend (cloud vs local) so PR gates can use a cheaper local model and nightly runs use a stronger one

8. Beyond Text: Voice, Multi-Turn, and Silent Regressions

Text WebSocket cases are necessary but not sufficient. Three surfaces traditional frameworks almost always miss:

Voice / multimodal. A browser-driven voice harness injects TTS audio, waits for the agent reply, captures STT text, and runs the same semantic judge per turn. Failures that only appear when latency, barge-in, or audio pipeline drift — invisible to pure API tests — show up here. Headless CI support matters; voice suites are expensive, so treat them like LLM benchmarks: nightly or on-demand, not on every commit.

Multi-turn user simulation. Real users do not send one perfect query. An LLM-powered user simulator drives follow-ups (“cheaper ones”, “only sleeper”, “what about refunds?”) against the live agent. Assertions attach per turn: state should accumulate, agents should not restart the whole plan from scratch, and the final answer must remain faithful to the full conversation — not just the last utterance.

Analytics and event contracts. GA / product-analytics payloads can break with no UI symptom. Network capture (e.g. BiDi) validating event names, params, and sequencing turns “silent” instrumentation regressions into ordinary CI failures. The same idea applies to any side-channel your product depends on but users never see.

These belong as sibling modules, not bolted scripts: they reuse core config, the semantic assertion API, and the shared results store so a voice failure and a backend failure appear on the same dashboard timeline.

9. Integration: The Whole Truth

Individual modules verify their layer. The integration module verifies the whole journey: a user query triggers a WebSocket, which invokes agents, which call LLMs, which drive the UI. Scenarios here catch the bugs no single module can see.

10. Dashboard: Visibility Or It Didn’t Happen

A test that runs but isn’t seen is a test that doesn’t exist. A Spring Boot dashboard, backed by PostgreSQL, exposes:

• Overview: pass/fail counts across all modules
• Per-module deep dives with historical trends
• Performance dashboards (p50/p95/p99 latencies over time)
• LLM leaderboards
• REST APIs so other tools can subscribe

Data Flow

Every test run produces a TestRun record with a unique ID. Every assertion within it produces a TestResult tagged with module, protocol, and semantic scores. This tagging makes cross-cutting queries — “show me every failure for a given flow across all protocols in the last 7 days” — trivial.

CI/CD Integration

A Jenkins (or GitHub Actions, or GitLab CI) pipeline stitches everything together:

1. Checkout and cache dependencies
2. Build all modules in parallel
3. Unit tests — fast feedback under 2 minutes
4. Protocol suites — WebSocket, gRPC, SSE run in parallel
5. Backend flow tests — the semantic-heavy suite
6. UI E2E — headless, sharded across executors
7. Voice / multi-turn — nightly or on-demand (browser + TTS/STT cost)
8. LLM benchmarks — nightly or on-demand (cost management)
9. Publish — Allure reports, dashboard push, Slack/email notifications

The key insight: not every stage runs on every commit. Fast checks gate PRs; expensive checks run on merge to main or on schedule.

Lessons Learned

A few things worth internalizing before you build:

• Start with core and one module. Do not build the full tree upfront. Ship WebSocket + one backend flow case, prove the pattern, then replicate.
• YAML is a contract, not a config. Treat test-case schemas with the same rigor as production APIs. Version them.
• Fail cheap before you judge. Agent-set and state checks catch many “fluent but wrong” bugs without a judge-LLM invoice.
• Semantic validation is the multiplier. A hundred structural tests catch fewer real bugs than ten well-written semantic tests — but only when thresholds and rubrics are scenario-specific.
• Text is not the whole product. Voice, multi-turn, and analytics contracts fail in ways UI smoke tests never see.
• Own your dashboard. Bolted-on reporting tools become bolted-off within a year.
• Measure the framework itself. Track flakiness per test, per module, and judge disagreement rate. Retire tests that fail intermittently — they cost more than they catch.

Where to Take It Next

Once the foundation holds, natural extensions appear:

• Chaos testing — inject latency, drop connections, and re-run the same suite
• Contract testing — capture and replay protocol schemas to catch breaking changes early
• Synthetic monitoring — reuse the same test cases as production canaries
• Agentic test generation — let an LLM propose test cases from user-conversation logs

If you’re building or evolving a test platform for agentic systems, the patterns above have held up across WebSocket, gRPC, SSE, and A2A protocols — across voice and multi-turn flows — and across half a dozen frontier LLMs. The sleeper-bus class of bug is why the stack exists. Steal freely.

Designing a Modular Test Automation Framework for Agentic AI Systems was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

How RedBus improved conversion, reduced OTP costs, and strengthened security

Overview

RedBus operates across multiple countries, serving millions of users booking intercity travel. With a diverse, multilingual user base and varying levels of network reliability, authentication has historically been a key friction point — especially when relying on SMS-based OTPs.

To improve user experience and reduce operational costs, RedBus introduced passkeys as a modern, passwordless authentication method.

The challenge

RedBus faced several authentication challenges across its markets:

1. High friction during critical booking moments

Users were frequently asked to sign in at high-intent stages:

• Homepage login prompts
• Seat selection (to unlock offers)
• Payment page (to apply discounts or complete booking)

Each interruption increased drop-off risk.

2. OTP reliability and cost issues

• SMS delivery failures in certain regions
• Latency causing delayed OTPs
• High cost per OTP, especially in international markets

3. Lost users due to session drops

• Users navigating back from payment pages often needed to re-authenticate
• Re-login friction reduced chances of conversion recovery

4. Security concerns

OTP-based systems are vulnerable to:

• SIM swap attacks
• Phishing
• Interception

The solution: Passkeys

RedBus implemented passkeys as a seamless and secure alternative to OTP-based login.

Passkeys allow users to authenticate using:

• Device biometrics (fingerprint, face unlock)
• PIN or system authentication

This eliminates the need for passwords and OTPs entirely.

Where passkeys made the biggest impact

1. Seamless login from homepage

Users can sign in instantly with a biometric prompt — no typing, no waiting.

Impact: Faster onboarding and higher login completion rates.

2. Offer unlock during seat selection

When users attempt to access seat-level offers:

• Passkey prompt enables instant authentication
• No disruption to booking flow

Impact: Increased offer engagement and conversion.

3. Payment page authentication

Instead of OTP verification:

• Users authenticate with a single biometric action

Impact: Reduced drop-offs at the most critical funnel stage.

4. Back-button recovery flows

When users navigate back from payment:

• RedBus triggers a contextual popup with additional discounts
• Passkeys allow instant re-authentication

Impact: Higher retention and recovery of abandoned bookings.

Results

Explosive passkey adoption
Passkey registrations scaled rapidly over a short period

This represents >20x growth in daily adoption, driven by strategic placement in high-intent flows.

We are seeing ~25% passkey creation rate among daily active users, indicating strong user willingness to adopt passwordless authentication. However, repeat usage is still early-stage, which aligns with industry trends.”

Reduced authentication friction

• One-tap sign-in replaces multi-step OTP flows
• Consistent experience across devices and regions

Lower operational costs

• Significant reduction in SMS/OTP spend
• Particularly impactful in high-cost international markets

Improved reliability

• Eliminates dependency on telecom networks
• Near-zero failure rate compared to OTP delivery

Enhanced security

• Resistant to phishing and SIM swap attacks
• Credentials are device-bound and encrypted

Why passkeys work for RedBus

RedBus operates in a high-intent, time-sensitive booking environment. Users often:

• Book under time pressure
• Switch devices or networks
• Expect fast, uninterrupted flows

Passkeys align perfectly with these needs:

• Speed: Instant authentication
• Reliability: Works even with poor network conditions
• Security: Stronger than OTPs without added complexity

Key learnings

1. Introduce passkeys at high-friction points

Focus on:

• Payment steps
• Offer unlock flows
• Session recovery moments

2. Use contextual prompts

Trigger passkey login only when it adds value:

• Discounts
• Faster checkout
• Personalized experience

3. Educate users gradually

• Highlight “faster & safer login” benefits
• Use familiar biometric cues

What’s next

RedBus plans to:

• Expand passkey adoption across all markets
• Replace OTP as the default authentication method
• Optimize cross-device passkey usage

Authentication flow:-

Registration flow:-

Conclusion

By adopting passkeys, RedBus transformed authentication from a conversion bottleneck into a competitive advantage.

The shift not only improved user experience but also delivered tangible business benefits:

• Higher conversion rates
• Lower infrastructure costs
• Stronger security posture

Reducing Sign-in Friction Across Markets with Passkeys was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s fast-paced world, customer support agents are the frontline heroes of any business. They navigate complex systems, handle a wide range of customer issues, and strive to provide excellent service every single time. But what if we could give them a superpower? An AI-powered assistant to guide them, automate tedious tasks, and help them resolve customer issues faster and more effectively.

This is the story of CoPilot, an initiative to revolutionize our customer support by empowering our agents with the power of AI. In this blog post, we’ll take you through our journey of developing and launching CoPilot, the challenges we faced, and the incredible results we’ve seen so far.

The Challenge: A Day in the Life of a Customer Service Agent

Before CoPilot, our customer service agents faced several challenges that impacted their efficiency and job satisfaction:

1. Agent onboarding time — New agents required few months of intensive training to get up to speed with our complex processes
2. Process Adherence — High Average Handle Time (AHT) for inexperienced agents & more prone to making errors
3. Agent Inefficiency — Agents lost valuable time navigating multiple screens and performing manual tasks.

This clearly showed an opportunity for improvement through automation and a more streamlined workflow.

Introducing CoPilot: A Game-Changer for Agent Productivity

To tackle these challenges, we developed CoPilot, an AI-powered assistant integrated directly into the agent’s workspace. CoPilot provides real-time guidance, automates repetitive tasks, and consolidates workflows into a single screen.

Here’s how CoPilot helps our agents:

1. Real-time guidance suggests the next correct action, dramatically reducing training & onboarding time
2. Process-compliant suggestions minimize mistakes and improve consistency
3. Workflow automation consolidates tasks into a single screen, automating manual work and increasing efficiency

We opted for a hybrid model for CoPilot, combining AI for tasks like issue identification and generating summaries, with rule-based flows for process guidance to ensure sub-second response times, which is critical for agent adoption.

From Idea to Impact: The CoPilot Journey

We started our CoPilot journey with a Minimum Viable Product (MVP) focused on the process for a specific issue, based on the volume and complexity. We launched the MVP with a small team of agents and worked closely with them to gather feedback and iterate on the product.

This user-centric approach was crucial to our success. Here are some of the key learnings from our initial launch:

The Results Are In: CoPilot’s Impact on Performance

The results since the launch of CoPilot have been very promising. We’ve seen significant improvements in adoption, agent efficiency, and customer satisfaction.

CoPilot has seen strong adoption among our agents. As of March 2026, the adoption rates have stabilized around 90% resulting in 29% reduction in AHT for our chat process. Most importantly, CoPilot has had a positive impact on our Customer Satisfaction (CSAT) scores by 15%.

The Road Ahead: The Future of CoPilot

The journey with CoPilot is just beginning. Our goal is to expand CoPilot’s coverage to the majority of the issues keeping the adoption rate in check. To get there, we are focused on:

• Expanding to more issue types: We are planning to roll out CoPilot for other common issues.
• Continuous Improvement: We are constantly working on optimizing CoPilot’s flows, improving our AI models to reduce false positives, and incorporating agent feedback to make CoPilot even more intuitive and helpful.
• Deeper Automation: We are looking to further automate tasks such as case summarization, customer communication to free up even more time for our agents.

Conclusion

The results speak for themselves. CoPilot is more than just a productivity tool; it’s a paradigm shift in how we approach customer support. By empowering our agents with AI-driven insights and automation, we’ve not only seen remarkable gains in efficiency but also a significant uplift in customer satisfaction. This journey has reinforced our belief that investing in our agents’ success directly translates to a better experience for our customers.

The road ahead is exciting. As we expand CoPilot’s capabilities and tackle new challenges, we’re not just optimizing a process; we’re building a more intelligent, responsive, and human-centric customer support ecosystem. The story of CoPilot has just begun, and we’re thrilled to continue this journey of innovation, with our agents and customers at the heart of everything we do.

Revolutionizing Customer Support: The Story of redBus CoPilot was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

When a traveler is stranded at a bus stop at midnight, unsure if their bus is coming, the last thing they need is to wait in a chat queue or be involved in a lengthy chat with a customer support representative. They need answers — fast. This tension between the scalability of chat and the urgency of real-world travel problems is one we’ve been grappling with at redBus for some time. Our answer: Chat-to-Voice Deflection — a smarter, context-aware support system that puts the right channel in front of the right customer at exactly the right moment.

The Problem with One-Size-Fits-All Support

Our support ecosystem is built to be efficient. The Self-Help flow handles the bulk of common queries, and for more complex situations, customers are connected to a live chat human agent. Chat has clear operational advantages — a single human agent can manage multiple conversations simultaneously, letting us serve higher volumes without proportionally scaling headcount.

But efficiency has its limits.

Two metrics told us something was broken: chat drops and missed chats.

• Chat drops happen when a customer abandons the conversation after a human support agent has already connected — tying up that customer support representative in a dead-end interaction. The customer can typically abandon the conversation when the human agent is taking time to resolve an important issue that requires co-ordination with multiple parties.
• Missed chats occur when customers give up waiting in queue before reaching a human support agent at all.

These two problems feed each other in a vicious cycle. Chat drops occupy human chat agents unproductively → queues grow longer → more customers abandon before connecting → more pressure on the remaining chat agents. For customers dealing with a live journey crisis — a no-show bus, a safety concern, a wrong boarding point — every minute of that delay compounds their anxiety.

The numbers confirmed what we intuitively knew: chat CSAT consistently lagged behind voice CSAT for time-critical issues. When the human agents need to loop in bus operators or drivers to gather real-time information, relaying that back through text introduces friction and delay that a phone call would eliminate in seconds.

For certain situations, chat isn’t just suboptimal. It’s the wrong tool entirely.

The Solution: Give Customers a Choice — But Only When It Matters

We didn’t want to abandon chat. It remains the right channel for the majority of support interactions. What we needed was a way to intelligently surface voice support for customers who needed it most, without overwhelming our voice capacity or degrading the experience for everyone else.

The result is Chat-to-Voice Deflection: a hybrid support model that presents a “Call” option alongside “Chat” — but only under two specific conditions.

1. The Nature of the Issue

The problem must qualify as a real-time, journey-critical situation:

• Bus not showing up, breakdowns, or changes in boarding/drop-off points
• Safety concerns — harassment, accidents, or disrespectful staff behavior
• Operator-initiated bus cancellations
• Live tracking failures
• Boarding issues, such as needing the driver’s number or boarding point confirmation

2. The Timing

The customer must be within a defined window around their journey — currently 2 hours before departure or 2 hours after arrival.

Only when both conditions are met does the “Call” option appear. Everything else routes to standard chat. This precision ensures our voice support capacity is reserved for genuine emergencies, not routine queries.

Cutting the IVR Friction

One of the less obvious but significant wins of this feature is what it bypasses: our IVR system.

Traditional IVR flows — press 1 for this, press 2 for that — are a known pain point. Navigating a menu tree when you’re stressed and pressed for time is the opposite of helpful. While we’re actively rolling out an AI-powered voice bot to replace our legacy IVR, Chat-to-Voice Deflection offers an immediate shortcut: customers are connected directly to a live customer support representative, skipping the IVR tree entirely.

For someone in crisis, that’s not a small thing. It’s the difference between feeling supported and feeling abandoned.

The Results: Metrics That Matter

We launched Chat-to-Voice Deflection towards the end of last year, and the data has exceeded our expectations.

Customers Voted with Their Fingers

When given the choice, customers in urgent situations overwhelmingly chose to call with more than 50% customers preferring voice over chat. The preference is on similar lines for women travellers. The signal is clear: when customers in distress are given the option to speak to someone, they take it.

Additionally we saw a significant drop in missed chats while the chat CSAT also showed an improvement.

The Bigger Picture

At its core, Chat-to-Voice Deflection is about meeting customers where they are — not just geographically, but emotionally. A traveler dealing with a journey crisis isn’t just looking for information. They’re looking for reassurance. And sometimes, only a human voice can provide that.

By marrying the efficiency of chat with the empathy of voice, we’re not just improving metrics. We’re making the promise of a smooth journey feel a little more real — even when things don’t go according to plan.

From Chat to Talk: redBus’ Story of Enhancing Customer Support for Real-Time Issues was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The transition from AWS Elasticache(Redis) to DragonflyDB at Redbus was initiated to solve hardware underutilization and improve performance-per-dollar. As of early 2026, the migration is nearing completion with significant gains in memory efficiency, throughput and dollar savings.

2. Dragonfly Architecture

Dragonfly is a Redis- and Memcached-compatible, high-performance in-memory data store designed as a drop-in replacement for Redis, built from the ground up with a modern architecture.

• Thread-per-core, shared-nothing architecture: Leverages all CPU cores efficiently through vertical scaling. The dataset is sharded, with each shard managed by a dedicated thread, minimizing locks and synchronization.
• Efficient inter-thread communication: Achieved through message passing, avoiding shared memory contention.
• Custom fiber-based framework: Built on C++ stackful fibers (similar to Go’s goroutines) to abstract I/O operations and manage concurrency within each thread.
• Snapshotting with io_uring: Uses Linux’s efficient async I/O interface instead of Redis traditional fork + copy-on-write (COW), significantly improving I/O performance.
• Data structure enhancements:
• DashTables: Replaces traditional Redis hashtables for better memory efficiency and performance.
• B+ Trees: Used for sorted sets to optimize indexing and range queries.
• SSD-based tiering: Introduced specifically for string values to allow datasets to exceed available RAM.
• Command support: While Dragonfly supports most Redis commands, not all are implemented yet.
• Licensing: Released under Business Source License 1.1 (BSL 1.1) — free for internal use, but restricted from being offered as a managed service.

3. Setup & Performance Benchmarking: Dragonfly vs. Valkey vs. Redis

Although Redis and Valkey are largely identical, we enabled I/O threading in Valkey (with 6 threads) to evaluate how Redis/Valkey compares to Dragonfly, which was run with 8 threads (utilizing all available CPU cores).

Infrastructure

• Cache Server: 8-core, 64 GB RAM
• Client machine: 4-core, 8 GB RAM
• Tool: memtier_benchmark (Redis Labs)

Techstack Versions

• Redis: Community Edition May 2025
• Valkey: Latest version May 2025
• Dragonfly: Community Edition 1.29.x April 2025

3.1 Benchmark : String SET & GET

Conclusion: Dragonfly outperforms Redis and Valkey (except in p99.9 latency).

Dragonfly vs Redis

• Winner: Dragonfly
• SET: ~239% higher operations/sec, ~70% lower average latency, ~29% less RAM than Redis
• GET: ~200% higher operations/sec, ~67% lower average latency, ~29% less RAM than Redis
• Snapshot: ~62% smaller snapshot size than Redis
• CPU: higher CPU (538%–843%) than Redis.

Valkey vs Redis

• Winner: Valkey (except for snapshot size)
• SET: ~107% higher operations/sec, ~51% lower average latency, slightly higher RAM than Redis
• GET: ~109% higher operations/sec, ~52% lower average latency, ~1% less RAM than Redis
• Snapshot: ~60% larger snapshot size than Redis
• CPU: higher CPU (506%–681%) than Redis.

Dragonfly vs Valkey

• Winner: Dragonfly (except for p99.9 latency)
• SET: ~64% higher operations/sec, ~38% lower average latency, ~29% less RAM than Valkey
• GET: ~44% higher operations/sec, ~30% lower average latency, ~29% less RAM than Valkey
• Snapshot: ~76% smaller snapshot size than Valkey
• CPU: higher CPU (5%–21%) than Valkey.
• Valkey outperforms Dragonfly for SET by 7% in p99.9 latency, for GET by 16% in p99.9 latency (reasons unknown).

3.2 Benchmark : Sorted Sets (ZADD, ZRANGEBYSCORE)

Conclusion: Dragonfly outperforms Redis (except in ZADD p99.9 latency) and Valkey (except in ZADD p99 & p99.9 latency).

Dragonfly vs Redis

• Winner: Dragonfly (except for ZADD p99.9 latency)
• ZADD: ~220% higher operations/sec, ~67% lower average latency, ~43% less RAM than Redis
• ZRANGEBYSCORE: ~183% higher operations/sec, ~64% lower average latency, ~40% less RAM than Redis
• Snapshot: Slightly higher snapshot size than Redis
• CPU: higher CPU (189%–438%) than Redis.
• Redis outperforms Dragonfly for ZADD by 341% in p99.9 latency (reasons unknown).

Valkey vs Redis

• Winner: Valkey (except in snapshot size)
• ZADD: ~99% higher operations/sec, ~49% lower average latency, ~14% more RAM than Redis
• ZRANGEBYSCORE: ~118% higher operations/sec, ~54% lower average latency, ~10% more RAM than Redis
• Snapshot: Slightly higher snapshot size than Redis
• CPU: higher CPU (241%–472%) than Redis.

Dragonfly vs Valkey

• Winner: Dragonfly (except in p99 & p99.9 latency)
• ZADD: ~61% higher operations/sec, ~35% lower average latency, ~50% less RAM than Valkey
• ZRANGEBYSCORE: ~30% higher operations/sec, ~22% lower average latency, ~45% less RAM than Valkey
• Snapshot: Slightly higher snapshot size than Valkey
• CPU: lower CPU (6%–15%) than Valkey.
• Valkey outperforms Dragonfly for ZADD by 97% in p99 latency and ~645% in p99.9 latency (reasons unknown).

3.3 Benchmark : Hash (HSET, HMGET)

Conclusion: Dragonfly outperforms Redis and Valkey (except for HMGET in p99 & p99.9 latency).

Dragonfly vs Redis

• Winner: Dragonfly
• HSET: ~258% higher operations/sec, ~72% lower average latency, ~5% less RAM than Redis
• HMGET: ~102% higher operations/sec, ~50% lower average latency, ~5% less RAM than Redis
• Snapshot: ~84% lower snapshot size and ~94% lower snapshot time than Redis
• CPU: higher CPU (250%–605%) than Redis.

Valkey vs Redis

• Winner: Valkey (except in snapshot time)
• HSET: ~83% higher operations/sec, ~45% lower average latency, ~3% more RAM than Redis
• HMGET: ~92% higher operations/sec, ~47% lower average latency, ~3% more RAM than Redis
• Snapshot: same snapshot size but ~1% higher snapshot time than Redis.
• CPU: higher CPU (241%–516%) than Redis.

Dragonfly vs Valkey

• Winner: Dragonfly (except in p99 & p99.9 latency)
• HSET: ~95.3% higher operations/sec, ~49% lower average latency, ~8% less RAM than Valkey
• HMGET: ~5% higher operations/sec, ~4% lower average latency, ~8% less RAM than Valkey
• Snapshot: ~83% lower snapshot size and ~94% lesser snapshot time than Valkey
• CPU: higher CPU (3%-14%) than Valkey.
• Valkey outperforms Dragonfly for HMGET by 16% on p99 latency and 32% for p99.9 latency (reasons unknown).

3.4 Benchmark : LIST (LPUSH, LRANGE)

Conclusion: Dragonfly outperforms Redis (except for snapshot size & time) and Valkey (except in p99 & p99.9 latency, snapshot size & time).

Note: The benchmark involved pushing 8 crore events into a list — an unrealistic scenario, solely done for testing purposes.

Dragonfly vs Redis

• Winner: Dragonfly (except for snapshot size and time)
• LPUSH: ~194% higher operations/sec, ~65% lower average latency, ~1% less RAM than Redis
• LRANGE: ~38% higher operations/sec, ~26% lower average latency, ~11% less RAM than Redis
• Snapshot: ~1865% larger snapshot size and ~2914% higher snapshot time than Redis
• CPU: higher CPU (237%–321%) than Redis.

Valkey vs Redis

• Winner: Valkey (except in snapshot time)
• LPUSH: ~125% higher operations/sec, ~55% lower average latency, slightly higher RAM as Redis
• LRANGE: ~79% higher operations/sec, ~44% lower average latency, ~15% less RAM than Redis
• Snapshot: slightly higher snapshot size and time compared to Redis.
• CPU: higher CPU (309%–480%) than Redis.

Dragonfly vs Valkey

• Winner: Dragonfly (except in snapshot and LRANGE latency)
• LPUSH: ~31% higher operations/sec, ~21% lower average latency, ~1% less RAM than Valkey
• LRANGE: ~23% lesser operations/sec, ~32% higher average latency, ~5% more RAM than Valkey
• Snapshot: ~1862% larger snapshot size and ~2937% higher snapshot time than Valkey
• CPU: higher CPU (17%-27%) than Valkey.
• Valkey outperforms Dragonfly for LPUSH its 18% in p99 latency, for LRANGE its 618% on p99 latency and 415% for p99.9 latency (reasons unknown).

3.5 Benchmark : Set (SADD, SISMEMBER)

Conclusion: Dragonfly outperforms Redis (except for snapshot size & time) and Valkey (except for SADD in p99 latency, snapshot size & time).

Note: The benchmark involved pushing 4 million events into a set — an unrealistic scenario, solely done for testing purposes.

Dragonfly vs Redis

• Winner: Dragonfly (except in snapshot time)
• SADD: ~180% higher operations/sec, ~63% lower average latency, ~13% less RAM than Redis
• SISMEMBER: ~182% higher operations/sec, ~63% lower average latency, ~3% less RAM than Redis
• Snapshot: Slightly higher snapshot size and 42% to 46% higher snapshot time than Redis
• CPU: higher CPU (194%–479%) than Redis.

Valkey vs Redis

• Winner: Valkey (except in snapshot time)
• SADD: ~122% higher operations/sec, ~55% lower average latency, slightly lower RAM than Redis
• SISMEMBER: ~149% higher operations/sec, ~59% lower average latency, ~5% higher RAM than Redis
• Snapshot: similar snapshot size but 3% higher snapshot time than Redis.
• CPU: higher CPU (226%–484%) than Redis.

Dragonfly vs Valkey

• Winner: Dragonfly (except in SADD p99 latency)
• SADD: ~26% higher operations/sec, ~18% lower average latency, ~12% less RAM than Valkey
• SISMEMBER: ~13% higher operations/sec, ~10% lower average latency, ~7% less RAM than Valkey
• Snapshot: Slightly higher snapshot size and 47% to 51% higher snapshot time than Valkey
• CPU: lower CPU (1%-10%) than Valkey.
• Valkey outperforms Dragonfly for SADD by 17% in p99 latency (reasons unknown).

3.6 Final summary

Disclaimer: We are publishing our findings as found in the setup and the tech stack versions listed above.

Performance

• Across benchmarks, Dragonfly overall outperforms Redis and Valkey.
• Dragonfly has consistant p99 latencies than Valkey or Redis.
• Snapshot sizes are sometimes larger, likely due to extreme benchmark scenarios involving heavy List and Set usage but nonetheless needs to be checked with the dragonfly team.

Scalability

• Dragonfly scales impressively with more CPU cores, challenging Redis single-threaded, horizontally-scaled philosophy.
• Dragonfly supports horizontal scaling as well, enabling performance improvements through both vertical and horizontal scaling.

Setup & Support

• Setting up Dragonfly is straightforward — it’s a lightweight binary with a configuration process similar to Redis. You can use redis-cli to interact with it.
• While Dragonfly doesn’t yet support the full set of Redis commands, its feature set is actively growing and already covers the majority of use cases within Redbus.

Stability & Reliability

• Dragonfly is production-ready and already adopted by many companies, however it remains a relatively new and evolving player in the in-memory database space — unlike Redis, which is a mature, battle-tested solution with years of stability and community trust.

Conclusion

Overall Dragonfly is a strong modern alternative to Redis that remains bottlenecked by its single-threaded nature., offering excellent hardware utilization and performance-per-cost. That said, we recommend evaluating it thoroughly against your specific workload before adoption.

4. Migration & Adoption Status (March 2026)

Redbus decided to migrate to Dragonfly cloud. Redbus has seen aggressive adoption across its global cloud infrastructure with ~90% of total caches migrated.

5. Cost Savings & Optimization Opportunities

By migrating to Dragonfly cache we have targeted to save atleast ~40% compared to our earlier spends on AWS Elasticache(with a savings plan). Savings are much higher compared to on-demand costs.

6. Contributors

• Harsha Nanjundaiaha
• Nitish P
• Swatik J Shetty
• Tanveer M

7. References

1. https://www.dragonflydb.io/blog/redis-and-dragonfly-architecture-comparison
2. https://github.com/dragonflydb/dragonfly
3. https://redis.io/
4. https://github.com/valkey-io/valkey

Redbus Journey: DragonflyDB Evaluation & Adoption (2025–2026) was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article examines “thoughtful leadership,” a concept championed by Anoop Menon, CTO of redBus, particularly concerning the strategic dilemma of prioritizing “core work versus patching on top of it.”

Thoughtful leadership, in this context, focuses on evolving organizational processes to sustainably improve the productivity of deliverables. Instead of constantly seeking new approaches, the emphasis should be on integrating modern AI tools, to enhance existing delivery models and developer productivity.

The Trap of Short-Term Fixes

Leaders frequently introduce new solutions to recurring problems. However, these fixes often provide only temporary relief, allowing the fundamental issues to resurface. This leads to a continuous cycle of new patches rather than a deep investigation into the root cause and the implementation of a sustainable resolution. While short-term patches can temporarily free up time for routine tasks, organizations inevitably revert to old problems or require yet another fix.

Organizational Noise and Adoption Challenges

Introducing numerous new approaches can create significant organizational “noise,” demanding substantial time for adoption and adjustment across all levels, from senior engineers to those at the bottom of the structure. Process changes sometimes necessitate a profound cultural shift, and their long-term outcomes are often hard to predict or articulate. Despite the initial appeal of new changes and notions, they can potentially have negative organizational consequences.

Focusing on Sustainable Improvement

While change is essential for a growing organization, merely patching existing problems is ineffective and often just generates the need for more patches. As Anoop Menon emphasizes, the focus should shift from constantly rebuilding solutions around a problem to understanding and improving current processes. This is achieved through cultural shifts or targeted employee training to enhance overall organizational effectiveness.

Resistance to restrictions on change in a dynamic world is a common reaction. Yet, the fundamental issues often remain constant, frequently stemming from internal skill or will deficiencies, rather than flaws in the processes themselves.

The Thoughtful Approach

Therefore, a thoughtful response to a changing world is not necessarily the adoption of entirely new processes, but the intelligent integration of new technology within existing ones. The priority must be on enhancing the delivery of objectives, avoiding the unproductive cycle of endless new solutions and process overhauls.

Ultimately, as the CTO advises, the focus should be on customers, not internal processes. The goal is for the existing process to evolve the people, rather than people continually inventing new processes to solve the same old problems.

The Essence of Thoughtful Leadership: Improving Core Processes Over Constant Patching was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Business Challenge: The “Human-in-the-Loop” Bottleneck

In the high-stakes world of travel logistics, pricing is a living organism. At redBus, beside our revMax engine which takes care of dynamic pricing for the buses, it manages multiple vendors on ground update requests on realtime via communication channels. Historically, these updates were sent as a chaotic stream of natural language messages via Telegram. A team of Pricing Analysts then had to manually parse these messages, log into internal tools, and execute the changes.

In the current AI landscape, there is a massive gap between a “cool chatbot demo” and a “production-ready execution engine.” When your system is responsible for real-time pricing and revenue management — as we do at redBus with our revMax ecosystem—"mostly accurate" isn't an option.

To handle high-frequency fare updates across hundreds of vendors on Telegram/WhatsApp, we didn’t just need a chat interface; we needed a Deterministic AI Agent. Using Google’s Agent Development Kit (ADK) and the Gemini model family, we built a system that translates messy human intent into high-precision database transactions.

Here is the architectural blueprint for building a reliable, scalable AI agent from the ground up.

1. The Core Philosophy: Contextual Intelligence & Deterministic Integrity

Separating the Probabilistic from the Deterministic

The biggest mistake in AI engineering is asking a Large Language Model (LLM) to perform business logic. LLMs are probabilistic — they predict the next most likely word. Database writes, however, must be deterministic.

Our architecture follows a strict Separation of Concerns:

• The LLM (The Translator): Its only job is to map natural language (e.g., “update Set category 1 to 749 for Hyd-Shirdi tomorrow”) into a structured, machine-readable JSON schema.
• The Code Layer (The Executor): A Java-based service that takes that JSON, validates it against business rules, and executes the transaction.

2. Single-Pass Orchestration via ADK

Many AI systems suffer from “Chaining” — calling the LLM 5 or 6 times to resolve different parts of a request. This leads to high latency and “error compounding.”

Using the ADK framework, we optimized for a Single-Pass Architecture. We provide the model with a rich “System Instruction” and Few-Shot Examples at runtime. This allows the model to identify the intent, route, and fare values in a single few-seconds window, rather than a multiple-seconds chain.

The Request Lifecycle:

1. Ingestion: The Telegram payload hits our ADK server.
2. Intent Mapping: The LLM produces a structured JSON output:

{
“intent”: “CAPPING”,
“route”: “HYD-SHRDI”,
“date”: “2026–04–06”,
“updates”: [{“category”: 1, “value”: 749}]
}

3. Solving for the “Vagueness Problem”

Human communication is rarely perfect. An operator might say “Update the price,” even if they have three different buses leaving for that route.

To solve this, we implemented Stateful Multi-Turn Sessions:

• Context Persistence: We use MongoDB to maintain a 10-minute “conversation state.”
• Intelligent Pushback: If the LLM identifies multiple matching services, it is instructed to trigger a MULTIPLE_SERVICES_FOUND event. The bot asks the user for clarification (e.g., "9:30 PM or 10:45 PM?").
• State Merging: When the user replies, the system merges the new information with the previous context to complete the request.

The following diagram provides a bird’s-eye view of how a messy human request is structured, validated, and executed in real-time (“Transforming Natural Language into Deterministic Fleet Commands”)

4. Engineering for Scale and Resilience

Building for production means planning for failure. Our architecture includes three “hardened” engineering patterns:

• High-Concurrency Parallel Execution: Pricing updates often involve a “fan-out” effect — for instance, a single request might trigger updates across 15 different sub-routes. To prevent bottlenecks, we utilize Java’s IntStream.parallel() to process these updates concurrently. This ensures our end-to-end response time remains at a consistent 4 seconds, regardless of the request’s complexity or volume.
• Hot-Swappable Model Failover: In a live environment, model downtime or rate-limiting is an unavoidable reality. We implemented a Model Gateway within Redis that monitors performance in real-time. If the primary model (e.g., Gemini Pro) hits a latency spike or a 429 error, the system automatically flips traffic to a secondary model (Gemini Flash) and alerts the engineering team via webhooks, ensuring zero service interruption.
• Fuzzy Service Resolution Layer: To eliminate the risk of the LLM “hallucinating” Database IDs, we offload service identification to a dedicated code layer. This layer performs fuzzy matching against a Redis cache of active services, applying a ±30 minute tolerance for departure times. This allows the system to remain robust even when operators use shorthand or round off departure times (e.g., identifying a “9:25 PM” bus when the user types “9:30 PM”).

5. The Impact: Redefining Operational Velocity

By moving from manual intervention to a deterministic AI agent, we didn’t just “save time” — we created a new standard for fleet management:

• Autonomous Operations: 54% of all pricing requests are now handled with zero human intervention.
• Elastic Scale: We scaled from zero to 100+ high-tier vendors with no increase in headcount.
• Cost Efficiency: By collapsing the logic into a single-pass architecture, we reduced API token costs by 98%.

Final Thoughts

The future of AI in the enterprise isn’t about building “chatty” assistants. It’s about building Silent Operators — systems that use the linguistic power of LLMs to bridge the gap between human messiness and digital precision.

By leveraging the ADK framework and a deterministic execution layer, we’ve proven that AI can be as reliable as any other part of the core engineering stack.

Architecting for Determinism: Building Production-Grade AI Agents for Fleet Operations was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

A deep dive into the Aerospike-powered architecture for our real-time train inventory aggregator.

At redBus, while we are widely known for bus ticketing, we also operate a rapidly growing train ticketing vertical. The engine behind this is our real-time train inventory aggregator system, a platform that needs to be incredibly fast, resilient, and scalable. As our data volume grew, we found that our reliance on traditional memory-based caching systems was becoming a bottleneck, leading to soaring infrastructure costs.

To solve this, we adopted Aerospike as the real-time database for our train inventory platform. The results have been transformative. Today, this system handles a staggering 120,000 reads per second, with a p99 latency of less than 1 millisecond.

This article is the story of how we did it. We’ll cover our architecture, our cluster configuration, and the key optimizations — like batch queries and bin projection — that helped us not only achieve massive performance gains but also reduce our client-side infrastructure by 30%.

The Challenge: Speed and Cost-Efficiency for a Real-Time Aggregator

Our previous setup, while performant, relied on a system that was primarily memory-driven. As our aggregated train inventory data scaled, so did the need for more RAM, which directly translated to higher and unsustainable infrastructure costs. We needed a solution that could provide the speed of an in-memory database but with the cost-efficiency of a disk-based system.

Aerospike’s Hybrid Memory Architecture (HMA) was the perfect answer. It stores indexes in RAM for lightning-fast lookups while keeping the actual data on SSDs. This model offered the best of both worlds: the sub-millisecond latency our real-time aggregator required, at a fraction of the hardware cost.

Our Aerospike Architecture for Train Inventory

To support our read-heavy workload, we designed a robust and scalable cluster. The architecture is built for high availability and throughput, ensuring that our train inventory system is always online and responsive.

Our production cluster consists of 2 nodes, configured with a replication factor of 2 to ensure data durability and high availability. This setup allows us to handle node failures without any service disruption and provides the read capacity needed to serve our traffic.

Unlocking Efficiency: From Point Lookups to Batch Queries

Initially, our services fetched inventory data using individual point queries for each item. While this approach was simple, it was inefficient at scale. Each query carried its own network overhead, and with thousands of requests per second, this overhead added up, putting a significant strain on both the client machines and the network.

The game-changer was switching to Aerospike’s batch queries.

Instead of sending thousands of individual get() requests, we now group multiple keys into a single getBatch() request. The server processes these keys in parallel and returns all the records in one response.

The impact was immediate and profound:

1. 30% Reduction in Client Infrastructure: By drastically reducing the number of outbound connections and network chatter, we saw a significant drop in CPU and memory usage on our client-side applications. This allowed us to scale down our client fleet by 30%, a massive cost saving.
2. Reduced Latency: Consolidating multiple network round-trips into one significantly lowered the overall latency for fetching a collection of inventory items.

Here’s a conceptual look at how we use the Java client for batch operations.

import com.aerospike.client.AerospikeClient;
import com.aerospike.client.Key;
import com.aerospike.client.Record;
import com.aerospike.client.policy.BatchPolicy;

// ...

// 1. Create an array of keys for all the records you want to fetch.
Key[] keys = new Key[] {
    new Key("ns", "st", "key1"),
    new Key("ns", "st", "key2"),
    new Key("ns", "st", "key3")
    // ... add up to N keys
};

// 2. Execute a single batch read operation.
Record[] records = client.get(new BatchPolicy(), keys);

// 3. Process the results. The 'records' array contains all fetched records.
// The order of records corresponds to the order of keys requested.
for (Record record : records) {
    if (record != null) {
        // Process the record...
    }
}

Smart Data Fetching with Bins (Projections)

Another powerful feature we leverage heavily is bins. In Aerospike, a record is composed of named fields called bins (similar to columns in a SQL table). When you query a record, you don’t have to retrieve the entire object. You can specify exactly which bins you need.

By fetching only the necessary bins, we significantly reduce the payload size over the network, which further cuts down latency and client-side processing effort.

Here’s how we establish a connection using the Java client.

/ Placeholder for your Java client connection code snippet.
// Explain the key configuration parameters. For example:
import com.aerospike.client.AerospikeClient;
import com.aerospike.client.Host;
import com.aerospike.client.policy.ClientPolicy;
// ...
// 1. Define the hosts of your Aerospike cluster.
Host[] hosts = new Host[] {
 new Host("aerospike-node1", 3000),
 new Host("aerospike-node2", 3000)
};

// 2. Configure the client policy (e.g., timeouts, connection pools).
ClientPolicy policy = new ClientPolicy();
policy.user = "user";
policy.password = "pass";
policy.timeout = 50; // ms

// 3. Create and connect the client.
AerospikeClient client = new AerospikeClient(policy, hosts);

// The client is now ready to be used.

Keeping a Watchful Eye: Monitoring is Key

You can’t manage what you don’t measure. To ensure our Aerospike cluster runs smoothly, we have a comprehensive monitoring and alerting system built using Grafana and Prometheus.

We track a wide range of metrics in real-time, including:

• Operations/Sec: To monitor the read/write throughput.
• Latency: Tracking p95, p99, and p999 latencies for key operations.
• Success/Failure Rate: Alerting us immediately to any spike in errors.
• Disk & Memory Usage: To keep an eye on resource utilization and plan for capacity.

This dashboard gives us a live view of the cluster’s health and allows us to proactively address potential issues before they impact our users.

Final Thoughts

Adopting Aerospike for our train inventory aggregator was a strategic decision that paid huge dividends. We not only achieved our performance goals of handling over 120,000 reads/sec at sub-millisecond latency but also made our system more cost-effective and scalable for the future.

The key takeaways from our journey are clear: choosing the right tool for the job is critical, and continuous optimization — like moving from point queries to batching and using bin projections — can unlock massive efficiency gains.

We’re continuing to explore more of Aerospike’s capabilities and are excited about the future possibilities for our train platform.

Thanks for reading! Feel free to leave a comment below if you have any questions or want to share your own experiences with high-performance databases.

Originally published at https://medium.com on April 6, 2026.

How redBus’s Train Inventory System Handles 120,000 Reads/Sec with Sub-Millisecond Latency was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you look closely at how people book bus tickets, one thing becomes clear: the person booking the ticket isn’t always the one paying for it.

This happens more often than we think. A student booking a ticket home might ask a parent to pay. An employee might book travel while the company’s accounts team handles the payment. Friends planning a trip might split responsibilities: one finds the bus, another completes the payment.

For a long time, these situations were handled through the UPI Collect flow. The booker simply entered the payer’s UPI ID, a request was sent, and the payer approved it in their UPI app.

Before:

Booker → Enter UPI ID → Payer Approves → Booking Confirmed

March this year, that changed :

Following updated guidelines from the National Payments Corporation of India (NPCI), platforms like redBus had to remove the Enter UPI ID / Collect option to curb frauds

While necessary from a regulatory standpoint, it meant that a simple and familiar way for someone else to pay for a booking suddenly disappeared.

And that created a real problem.

Understanding What Customers Needed

When we looked at our data, we realised that thousands of customers every month rely on someone else to pay for their ticket.

Some common examples:

• Students booking tickets while their parents make the payment
• Family members helping relatives complete bookings

In some cases, the booker might not even have a bank account yet. In others, they simply prefer someone else to handle the payment.

Without the UPI Collect option, these customers had no simple way to ask someone else to complete the payment.

And if that happens at the payment page, the most likely outcome is simple, the booking never gets completed. Customer suffers and redBus too…

We knew we had to find a way to solve this quickly.

A Simple Idea: Share the Payment Page

Press enter or click to view image in full size

The idea that eventually became Share Payment Link was actually very straightforward.

If someone else needs to pay for the ticket, why not simply send them the payment page. That’s exactly what we built.

Now, when a customer reaches the payment page, they can generate a Share Payment Link and send it to the person who needs to complete the payment.

The payer opens the link, sees the same payment page, completes the payment, and the booking gets confirmed instantly. Just a simple way for two people to complete a booking together.

Built in Just Four Days

What makes this feature special internally is how quickly it came together.

Once the team understood the impact of removing UPI Collect, the goal was clear. We needed a solution fast so customers wouldn’t lose the ability to book tickets when someone else was paying.

Product, design, and engineering teams came together, aligned on the approach, and started building immediately.

From the first discussion to the feature going live on the platform, **Share Payment Link was designed, built, and launched in just four days.**

It was a great example of how quickly teams can move when everyone is focused on solving the same customer problem.

Customers Started Using It Immediately

We initially expected around 4,000 customers per day to use this feature, based on earlier usage patterns of UPI Collect.

But even with limited visibility inside the app, adoption picked up quickly. Thousands of customers have already started using Share Payment Link to complete bookings.

It confirmed something we already suspected — flexible payment options matter a lot in travel bookings.

What Customers Told Us (This matters to us the most):

To understand whether the feature was actually solving the right problem, we spoke to customers who had recently used Share Payment Link.

The responses were reassuring.

Nearly 90% of the customers we spoke to were using the feature for exactly the scenarios we had anticipated, such as a father paying for his daughter’s ticket or an accounts team completing payment for an employee’s travel.

Interestingly, some customers mentioned that they were not even aware of the earlier Collect flow. In those cases, they used workarounds like sharing screenshots of the payment page or coordinating over calls to get the booking completed, which was often inconvenient.

Many of them appreciated that redBus introduced a simpler way to handle these situations, making the process much smoother than before.

More importantly, every customer described the experience as simple and smooth.

They were able to share the link, complete the payment, and confirm the booking without any confusion.

Keeping Travel Simple

At redBus, our goal is simple — make it as easy as possible for people to plan and complete their journeys.

Sometimes that means adapting quickly when the payments ecosystem changes. And sometimes it means building small but meaningful features that reflect how people actually book travel.

Share Payment Link is one such example.

Because in the real world, the person planning the journey and the person paying for it are not always the same and that shouldn’t stop anyone from booking their trip.

Solving for Shared Payments: The Story Behind redBus’ Share Payment Link was originally published in redbus India Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.