Key takeaways
- District by Zomato connects movies, dining, live events, sports and stores through a unified going-out platform.
- Its business model combines ticketing, dining reservations, bill payments, memberships and partnerships.
- A District-like app requires a scalable architecture with reliable search, inventory management, booking workflows and payment integrations.
- Technologies such as Redis, PostgreSQL, Kafka and search indexes can support real-time bookings and high-demand operations.
- Building an experience booking app starts with a focused MVP, verified partners, secure payments and gradual category expansion.
District by Zomato is a multi-category going-out platform that brings movies, dining, live events, sports and stores into one app. Its business model is a useful case study in connecting discovery, bookings, payments and partner operations. The platform’s internal technology stack, however, is not publicly documented in the sources reviewed for this article.
So the technical sections describe our technical approach to a reference architecture for a similar app, not an insider view of District. The article covers the business model, reported financial results, the limits of public technology information, and the engineering decisions behind booking, search, traffic surges and AI. It closes with a practical route from idea to MVP.
Every figure carries its reporting period and source. Revenue, net order value and downloads measure different things, and mixing them leads to bad conclusions.
What Is District by Zomato?
District is the going-out app from Eternal, the company formerly known as Zomato Ltd. It launched as a standalone app in November 2024. Its official Google Play listing describes bookings for movies, events, dining, stores and sports, along with split bills, shareable reservations and saved-place Hotlists. The listing showed more than 10 million downloads when checked. Downloads are not active users.
How District connects movies, dining, events and sports
The product grew from Zomato’s dining-out business, which the company said was running at over $500 million in annualised gross order value before District launched. In 2024, Zomato also agreed to acquire Paytm’s entertainment and ticketing business for a reported ₹2,048 crore. Dining supplied restaurant relationships. The Paytm business supplied movie and event ticketing. One account, one payment layer and one discovery feed now sit across them.
How District differs from a conventional ticket-booking app
A traditional ticketing app handles one transaction: pick a show, pay, receive a ticket. District treats going out as a sequence. A user finds a place, books a table, splits the bill and returns next weekend.
Group features carry much of that sequence. Invitations, shared reservations and split payments mean state moves between friends, not just between one user and one venue. That overlaps with what a Social Networking App Development Company designs, such as shared state, notifications and permissions between connected users.
How the marketplace serves consumers and partners
District serves two sides. Consumers want accurate listings and fast checkout. Partners (cinemas, restaurants, organisers) want demand, reliable settlement and fewer no-shows. Adding a category adds a new type of partner and a new type of failure, which is where the operational cost of a multi-category app comes from.
How Does District by Zomato Make Money?
Eternal does not publish a commission breakdown for District, so exact take rates are unknown. The documented activities are ticketing, dining reservations and payments, and District Pass memberships. Anything beyond that, including individual revenue contributions, would be inference.
| Revenue source | Status | What is known |
|---|---|---|
| Movie, event and sports ticketing | Documented activity | Revenue split is not disclosed |
| Dining reservations and bill payments | Documented activity | Dining vouchers in District Pass show payments sit inside the flow |
| District Pass | Documented | Three-month membership. The official FAQ says the fee is non-refundable |
| Partnerships such as IPL ticketing | Documented partnership | The IPL named District official ticketing agency for the 2026 playoffs |
| Event production, promotions | Inferred | No source confirms a revenue contribution |
District Pass deserves a caution. The benefits and the price have changed across promotions, and city eligibility is set in the pass terms. Check the official terms before quoting any current benefit.
The booking pattern here, where a customer reserves a slot, pays and receives a confirmed service, is familiar to any On Demand App Development Company. The difference is that inventory here is scarce and time-bound. A seat for tonight’s match disappears.
Understanding revenue, NOV and adjusted EBITDA
These three terms are easy to confuse.
- Revenue is what the company recognises as its own income.
- Net order value (NOV) is the value of orders after discounts and promo codes. It describes the size of the transactions, not what the platform keeps.
- Adjusted EBITDA is a profit measure that excludes certain items.
A large NOV with a modest revenue figure is normal for a marketplace. Do not divide one by the other to guess a commission rate, especially across different periods.
What Do District by Zomato’s Financial Results Show?
Reported figures show fast growth with continuing losses. The table keeps each number with its period and source.
| Metric | Figure | Period | Source |
|---|---|---|---|
| Revenue | ₹207 crore, up 117.8% | Q1 FY26 | Business Standard |
| Annualised NOV | ₹8,000 crore | Q1 FY26 | Storyboard18, quoting Eternal |
| Customers | About 2 million average monthly transacting customers, ~2 transactions a month, net AOV above ₹1,700 | Q1 FY26 | Business Standard |
| Revenue | More than ₹970 crore | FY26 | The Ken |
| NOV | ₹2,736 crore, up 46.5% | Q4 FY26 | Financial Express |
| Adjusted EBITDA loss | ₹81 crore, from ₹121 crore | Q4 FY26 vs Q3 FY26 | Financial Express |
The FY30 ambition
In July 2025, Eternal said the going-out business could scale to a $3 billion annual topline with $150 million of adjusted EBITDA within five years, if executed well. Another outlet later described the goal as $3 billion of NOV by FY30. The wording differs, so check Eternal’s shareholder letters before quoting it as NOV.
Why downloads and order value are not profitability
A narrowing EBITDA loss is progress, not profit. High order value can still sit alongside losses if discounts, partner incentives and acquisition costs are heavy. Ten million downloads says little about repeat usage. The transacting-customer figure is the better engagement signal.
What Is Known About District by Zomato’s Technology?
District’s public-facing product and financial information can be verified. Its detailed internal technology stack cannot, based on the sources reviewed. The official listing shows the breadth of features. Financial reporting describes performance and an organisational move. Neither publishes a component-by-component architecture.
| Claim | Evidence status |
|---|---|
| Movies, events, dining, stores and sports in one app | Publicly documented (Google Play listing) |
| Technology stack and selected employees transferred to Wasteland Entertainment for ₹24.19 crore, effective May 1, 2026 | Reported (Financial Express). Components not disclosed |
| OpenSearch, Kafka-based CDC, Redis seat holds, PostgreSQL confirmation, SSE seat maps | Not confirmed in sources reviewed |
| A seven-minute seat hold, P99 discovery latency under 200 ms | Not confirmed. Omitted here |
| OpenAI or Apple models in production | Not confirmed. One developer account describes using language models to identify restaurants from shared Reels |
| Shared iOS and Android code | Not confirmed |
This evidence boundary matters because public tech-stack diagrams often show what an engineer would build, not what a company actually runs. The patterns below are sound engineering. They are not District’s confirmed implementation.
How to Design an App Architecture Like District by Zomato?
A District-like app needs two separate paths. Discovery is read-heavy and can tolerate data that is a few seconds old. Booking is write-sensitive and cannot tolerate inconsistency, because it involves scarce inventory and real money. Treating both as one workload is the most common design mistake in this category.
| Layer | Job | Possible options (illustrative) |
|---|---|---|
| Client and API gateway | Authentication, routing, rate limiting | Native or cross-platform app behind a gateway |
| Discovery service | Search, filters, location | A search index such as OpenSearch or Elasticsearch |
| Inventory service | Venues, shows, slots, availability | Relational database such as PostgreSQL |
| Booking service | Holds, confirmation, cancellation | Cache for holds, database for confirmation |
| Payment service | Charges, refunds, webhooks | Payment gateway with idempotent handlers |
| Event pipeline | Notifications, analytics, index updates | A message queue or log such as Kafka |
Mobile clients, APIs and authentication
The client should stay thin. Pricing, availability and booking rules belong on the server, so a stale app cannot sell a seat that no longer exists. Native versus cross-platform is a real trade-off. Cross-platform can speed up delivery, while native can help with heavy seat-map rendering. Teams weighing this usually need custom mobile app development advice tied to their own traffic and feature plans, not a generic recommendation.
Search, inventory and event processing
Search answers ‘what is on near me tonight?’. Inventory answers ‘is seat F12 still free?’. They have different consistency needs, so they use different stores. An event pipeline connects them: when inventory changes, the search index and notifications update asynchronously.
Analytics, recommendations and notifications
These consume events and should never block a booking. If the notification service is down, the booking still succeeds and the message is retried later.
Turn Your App Concept Into a Clear Architecture Plan features, integrations and scalable workflows. [Discuss Your App Idea]
How Can an App Like District by Zomato Prevent Double Bookings?
An app prevents double booking by making a seat reservation one atomic step. A seat moves from available to held only if it is currently available, and the hold expires if payment does not finish. The final booking is then written to a durable transactional database.
Atomic reservation holds
A common option is a Redis key set only if it does not already exist, with an expiry. The first request wins, and later requests fail immediately. A relational alternative is a conditional update on a status column. Hold length is a product decision. Pick one by testing the checkout flow, not by copying a number from a blog post.
Durable booking confirmation
The cache is a lock, not the record. Confirmation should be written in a database transaction so that losing the cache loses holds, not bookings. PostgreSQL is a sound choice for this role, which is a design principle and not a claim about District.
Payment idempotency and webhook handling
Idempotency means retrying the same operation does not create a second booking or charge. Payment gateways routinely send the same webhook more than once. Store each gateway event ID with a uniqueness constraint, so a repeat becomes a harmless no-op.
Payment code also carries security duties, including webhook signature checks, tokenised card data and audit logs. The Mobile App Security Best Practices guide covers those requirements in more depth.
Hold expiry, cancellation and reconciliation
Failures happen at the edges. A payment may succeed after the hold expired. A customer may close the app mid-payment. A scheduled reconciliation job should compare gateway records with bookings and resolve mismatches by refund or reallocation.
Concurrency testing under high demand
Test it before launch. Fire hundreds of simultaneous requests at one seat and assert that exactly one succeeds. Then repeat with payment failures and expired holds.
How Should Search and Discovery Work in an App Like District by Zomato?
Discovery should run on a search index, and booking truth should stay in the transactional database. A search index is built for text relevance, filters and distance. A transactional database is built for correctness. The index may lag by seconds, so any availability shown in search is a hint that must be re-checked at booking time.
Venue and event indexing, and location search
Index events, venues and showtimes with city, coordinates, category, language and time. Geo-distance filters power ‘near me’. Synonyms and spelling tolerance matter more than most teams expect, since people search for a comedian’s nickname or a half-remembered venue.
Keeping search indexes consistent with inventory
Change-data capture through Kafka is one way to stream database changes into the index. A transactional outbox or a scheduled reindex can be simpler for an MVP. The trade-off is freshness against operational complexity.
Caching, relevance and latency
Cache popular lists such as trending events and city homepages. Measure p95 and p99 latency on a defined workload, and track relevance through zero-result rate and click-through. Result ordering and empty states shape discovery as much as the index does, which is why the mobile app UI/UX design tips matter alongside the backend.
How Can an App Like District by Zomato Handle Traffic Surges?
A booking platform handles surges through controlled admission, rate limiting, queues and capacity planning. A major sales window, such as a playoff ticket release, can send far more users than seats in a few seconds. The goal is not to serve everyone instantly. It is to serve fairly without crashing checkout.
A virtual waiting room admits users in batches. A Redis sorted set is one implementation, ordering users by arrival time. Rate limits protect the gateway, and queues absorb payment confirmations so the booking service is not overloaded. This is backpressure: slow the inflow instead of collapsing.
Live seat maps need updates. Server-Sent Events are simple one-way pushes and work well through most proxies. WebSockets suit two-way interaction. Polling is acceptable at smaller scale. Choose by need, not fashion.
Watch queue depth, error rates and p99 latency, and rehearse failover before launch day. Profiling and load-testing methods are covered in our guide to mobile app performance optimization.
How Could AI Improve Discovery in an App Like District by Zomato?
AI can help with recommendations, understanding shared content and conversational planning. None of these is confirmed as a District production feature. One developer’s public account describes using language models to identify restaurants from shared Instagram Reels. That is a reported demonstration, not proof of platform-wide deployment.
Moneycontrol reported in July 2026 that thumpN was using AI-assisted discovery to surface overlooked live events. That points to a real opportunity: small events rarely win prominent placement, and good discovery can change that.
The risk is irrelevant or invented suggestions. Ground recommendations in the live catalogue, check availability before showing a result, and never let a model create an event that does not exist. Measure quality through saves, bookings after a recommendation and complaint rates. For wider context on where AI sits among platform decisions, see these mobile app development trends.
District by Zomato vs. BookMyShow, Swiggy Scenes and thumpN
The competitors differ more in scope than in technology, and no source reviewed here describes their stacks.
| Platform | Reported scope or evidence | Lesson |
|---|---|---|
| District | Movies, events, dining, stores and sports. Official IPL 2026 playoffs ticketing agency | Inventory access and partnerships matter as much as features |
| BookMyShow | Established in movie ticketing and live events | Incumbency brings trust and supply |
| Swiggy Scenes | Launched December 2024 inside the Swiggy app, focused on restaurant-hosted events. Check current scope | Distribution through an existing app is a different bet from a standalone one |
| thumpN | Reported in July 2026 as using AI-assisted discovery | Discovery can differentiate |
| Flipkart | Reuters reported plans in April 2026 to enter movie and concert ticketing. Launch status unconfirmed | Large consumer platforms see ticketing as an adjacent category |
District’s real difference is the move from one ticket to the whole going-out journey. A wide catalogue does not guarantee engagement, though. Reliable inventory, accurate schedules, clear pricing, easy refunds and responsive support decide whether people return.
How to Build an App Like District by Zomato
Start narrow. For most startups, one city and one category with verified supply will teach more than a thin multi-category launch. A multi-category app multiplies partner onboarding, support and failure modes before demand is proven.
- Choose the first market and category. Live music and comedy in one city is an example. Pick where you can secure supply.
- Validate demand and onboard partners. Sign venues and organisers before building features they will not use.
- Define the MVP and booking journey. Search, availability, hold, pay, confirm, ticket.
- Select architecture and integrations. Payments, maps, notifications and venue systems.
- Test payments, concurrency and failure recovery. Use the scenarios described above.
- Launch, measure retention and expand gradually. Add categories when repeat use justifies it.
Each step maps onto the stages in the app development lifecycle explained, from planning to maintenance. Once requirements are clear, a mobile app development company can turn them into a working application, including the integration and testing work that marketplaces demand.
How Much Does It Cost to Build an App Like District by Zomato?
Cost depends on scope, not on District’s name. Without fixed requirements, team location and currency, any single figure would be a guess. The drivers below move the budget most.
| Cost driver | Why it matters |
|---|---|
| Number of categories | Each adds partner types, rules and support needs |
| Integrations | Payments, maps, venue and cinema systems, notifications |
| Search and real-time features | Indexing, live seat maps and personalisation add engineering time |
| High-demand operations | Waiting rooms, load testing and extra capacity cost more to run |
| Security and compliance | Payment handling and data protection need careful work |
| Testing, support and maintenance | Ongoing cost often exceeds expectations |
An MVP in one category costs far less than a multi-category platform. Reviewing mobile app development services against your feature list is a practical way to get a requirements-based estimate.
Build an Experience Platform Inspired by District by Zomato
District by Zomato shows that the hard part of an experiences app is not the feature list. It is keeping discovery fast, inventory accurate and money safe when demand spikes. Reported results suggest the model can grow quickly, and they also show how costly that growth can be.
Use District as a case study for principles, not as a stack to copy. Validate a narrow market first, then build the booking path properly.
Frequently Asked Questions About District by Zomato
1. How is District different from BookMyShow?
District covers dining, events, sports, stores and movies in one app, according to its listing. BookMyShow is an established movie and live-events platform. Both compete for ticketing, and District’s wider scope is its main distinction.
2. What is District Pass?
District Pass is a three-month membership that gives savings on movies and dining, according to the official FAQ. Benefits, pricing and eligible cities change, and the fee is non-refundable. Check the current terms before purchase.
3. Why might a booking system use Redis and a relational database together?
Redis handles fast, temporary holds with expiry. The relational database stores confirmed bookings durably. If the cache fails, holds are lost but confirmed bookings stay correct.
4. How should payment webhooks prevent duplicate confirmations?
Store each gateway event ID with a uniqueness constraint. A repeated webhook then finds an existing record and does nothing, so one payment cannot confirm two bookings.
5. How can live seat maps reach users?
Server-Sent Events push updates one way and are simple to run. WebSockets suit two-way interaction, and polling works at smaller scale. Choose based on how interactive the seat map needs to be.
6. How can a startup compete with District and BookMyShow?
Pick a defensible niche, such as one city or one event type, and secure reliable supply. Win on accuracy, refunds and support before attempting breadth.
