Urban Company System Design Interview: Services Marketplace at Scale
Urban Company does not dispatch the nearest worker like a cab app. It books a plumber or a beautician into a time slot up to three days ahead, and the hard question is whether anyone will actually accept that slot. To answer it, Urban Company scores on the order of 1,100 professional-and-slot combinations for a single customer session, predicting the chance each pro accepts, serving about 6.8 million customers a year through tens of thousands of trained partners across 51 cities.
Designing Urban Company is the services-marketplace problem, which is different from ride-hailing. There is no instant dispatch of the nearest driver. A customer books a service, cleaning, a salon appointment, a repair, into a future time slot, and the system has to decide which slots to even offer and which professional to send, based on skill, location, availability, and, crucially, the predicted chance that a professional will accept the job. Urban Company has published how it models this with machine learning, treating reliability, the chance a booking is actually fulfilled, as the thing to optimize. It also manages and trains its supply rather than using an open pool. This walkthrough centers on the scheduled matching and reliability modeling Urban Company published, and is honest about which pieces are the general marketplace pattern.
Asked at: Commonly asked at Urban Company and marketplace and consumer-services teams, and the general forms, meaning design a services marketplace, a scheduling and matching system, or an appointment-booking platform, show up at most product companies for SDE2 and SDE3 rounds. Urban Company is a good question because it replaces instant dispatch with scheduled, skill-based matching and makes fulfillment reliability the core problem.
Why this question is asked
A services marketplace breaks the ride-hailing assumptions most candidates reach for. There is no nearest-driver dispatch, because the service is scheduled for a future slot and requires a specific skill, so the system must decide which time slots are even safe to show and which professional to route a request to. The hardest part is that a professional can decline, so the real question is not who is closest but who is likely to accept and deliver a scheduled job well. Urban Company published how it treats this as a prediction and reliability problem. It also manages its supply, training and certifying professionals, which changes the design from an open pool to a controlled asset. Interviewers use Urban Company to check whether you can design scheduled skill-based matching, reason about predicting acceptance and fulfillment reliability, and think about a marketplace where supply is curated rather than open.
Requirements
Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.
Functional requirements
- Customer picks a service and sees available time slots, up to a few days ahead
- Only slots that can realistically be fulfilled are offered, not every theoretical slot
- The system matches the booking to a suitable professional by skill, location, and availability
- A professional receives the request and can accept or decline it
- The customer gets a confirmed booking, tracks the professional on the day, and pays
- Professionals are onboarded, trained and certified, and progress through quality tiers
- Ratings and quality feedback flow back into who gets future requests
- Support multiple service categories, cities, and hyperlocal areas
Non-functional requirements
- Offer only slots likely to be fulfilled, so a customer is not booked into a slot no one accepts
- Score many professional-and-slot combinations quickly enough to render a booking screen
- Match on skill, location, and availability, not just proximity
- Optimize fulfillment reliability: minimize both no-response bookings and lost good requests
- High availability on the booking and matching paths
- Scale to millions of customers and tens of thousands of active professionals across many cities
- Keep supply quality high through training, tiers, and ratings
Back-of-envelope scale estimates
Show your math. Pulling numbers from thin air signals you have not thought about the load.
Annual transacting customers
~6.8M (FY25)
Urban Company reported about 6.8 million annual transacting customers in FY25. This is the demand side of the marketplace.
Active service partners
~48K monthly active
Urban Company reported about 47,888 average monthly active service partners in FY25. This managed, trained supply is what requests are matched to.
Cities and micro-markets
51 cities, 12,000+ micro-markets
Urban Company operates in 51 cities and divides them into more than 12,000 micro-markets of roughly 3 to 5 kilometers each, so matching and fulfillment are localized.
Scoring load per session
~1,100 scores/session
Urban Company reported scoring on the order of 1,100 combinations for a customer session, roughly 24 slots by 15 providers across 3 days, to decide which slots to show and whom to route to.
Slots offered
~72 per customer
Urban Company offers 24 slots a day from 8 AM to 7:30 PM, shown up to 3 days ahead, so about 72 bookable slots per customer. Deciding which of these are safe to show is the core problem.
Revenue
~1,144 crore rupees (FY25)
Urban Company reported revenue of about 1,144 crore rupees in FY25, up about 38 percent, turning profitable, and listed publicly in 2025. A sizing signal for the business.
High-level architecture
Design Urban Company around scheduled matching and fulfillment reliability, because those are what make it different from a cab app, and they are what Urban Company has published. The supply management and hyperlocal structure are stated facts, and the serving stack is described from Urban Company's own, somewhat older, engineering posts. The booking flow starts with slots, not dispatch. A customer chooses a service, and the system shows time slots, 24 a day from morning to evening, up to 3 days ahead, so about 72 slots. The critical decision is which of those slots to even offer, because showing a slot that no professional will accept leads to a booking that cannot be fulfilled. Urban Company answers this with prediction. It computes a Lead Score, the machine-learned probability that a specific professional will accept a specific request, and a Request Score, the probability that at least one eligible, available professional will accept a request for a given slot. The Request Score is what decides whether a slot is safe to show. Because there are many slots, many candidate professionals, and several days, a single customer session involves scoring on the order of 1,100 combinations, so the scoring has to be fast and is served by a dedicated matching service. The matching itself is skill-based and multi-signal, not nearest-first. Urban Company filters candidates by category skill, a facial specialist is not sent for a pedicure, by location proximity within the hyperlocal micro-market, and by availability state, whether a professional is on a job, at home, or offline, and by their history of accepting work. It scores the survivors with a gradient-boosted model, trained and tuned on managed cloud machine-learning infrastructure, across many service supercategories, and the scores are calibrated so that a predicted acceptance probability matches reality. Not every eligible professional sees every request; filtering happens first, and a request is routed to those most likely to accept and deliver well. The objective tying it together is reliability, framed as a trade-off. Urban Company optimizes between two failure modes: a No-Response request, where a booking is shown but no professional accepts, and a Requests-Lost outcome, where being too cautious blocks a request that could have been fulfilled. It uses causal modeling to balance these, with the guiding rule that blocking a likely-bad request must not cost more than one good request, and it reported measurable reductions in no-response rates after rolling this out. Around this sit the platform pieces Urban Company has described: a separate matchmaking service, an event-driven backbone using Kafka to connect microservices, Redis for caching, scheduling, and listing professionals, and a data pipeline feeding analytics, on cloud infrastructure. Supply is a managed asset: Urban Company trains and certifies professionals at scale and progresses them through quality tiers, and ratings feed back into who receives future requests.
In a real interview, sketch this on the whiteboard before diving into any single box.
Core components
Walk through each service. The interviewer wants to hear what each one owns, not just the names.
Slot and availability service
Presents bookable time slots, 24 a day up to 3 days ahead, and decides which are safe to show. A slot is only offered if a professional is likely to accept it, which is the Request Score's job. This is the scheduling core that replaces instant dispatch.
Matchmaking service
A dedicated service that scores professional-and-slot combinations and routes a request to the professionals most likely to accept and deliver. Urban Company runs this as a separate service because the scoring load, on the order of 1,100 scores per session, is heavy and specialized.
Lead Score model
The machine-learned probability that a specific professional will accept a specific request, given skill match, location proximity, availability state, and their acceptance history. A gradient-boosted model, trained and tuned on cloud machine-learning infrastructure and calibrated so a predicted probability matches real acceptance.
Request Score and slot gating
The probability that at least one eligible, available professional will accept a request for a given slot, computed from the Lead Scores of candidates. This gates which slots are shown, so customers are not offered slots that cannot be fulfilled, which is the central reliability lever.
Reliability optimizer
The layer that balances the two failure modes, no-response bookings versus lost good requests, using causal modeling, with the rule that blocking a likely-bad request must not cost more than one good one. Urban Company reported reduced no-response rates from this.
Supply management and training
The systems around a managed, trained workforce: onboarding, certification, and quality tiers that professionals progress through, plus ratings that feed back into matching. Because supply is curated rather than open, its quality and availability are part of the platform, not external.
Event backbone and data platform
An event-driven architecture using Kafka to connect microservices asynchronously, with Redis for caching, job scheduling, and listing professionals, and a data pipeline feeding analytics and the machine-learning models, on cloud infrastructure. This is the platform Urban Company described in its engineering writing.
Data model
Pick the right store per table. Justify each choice with the access pattern, not by reflex.
customerscustomer_id (PK)locationmicro_market_idcreated_atThe customer, placed in a hyperlocal micro-market so matching is localized. About 6.8 million transact a year.
professionalspro_id (PK)skills[]micro_market_idavailability_state (on_job|at_home|offline)tierratingacceptance_historyThe managed, trained supply. skills gate which requests they are eligible for, availability_state and acceptance_history feed the Lead Score, and tier and rating come from the quality loop. Live location history is bucketed relative to customers.
bookingsbooking_id (PK)customer_idservice_categoryslotpro_idstateamount_paisecreated_atA scheduled booking for a specific slot and service. state moves from requested through accepted, in progress, and completed, or cancelled. The slot is a future time, not now.
leadslead_id (PK)booking_idpro_idlead_scoresent_atresponse (accept|decline|no_response)A request sent to a professional, with its predicted Lead Score and the actual response. The gap between predicted and actual acceptance trains and calibrates the model.
slot_scorescustomer_idslotrequest_scorecomputed_atThe Request Score per candidate slot for a session, used to decide which slots to show. Ephemeral, recomputed per session over the ~1,100 combinations.
micro_marketsmicro_market_id (PK)citygeoradius_kmThe roughly 3-to-5-kilometer hyperlocal areas, more than 12,000 of them, that localize matching between customers and nearby professionals.
Deep dives
These are the conversations the interviewer is steering you toward. Practice each one until you can talk through it without notes.
Scheduled slot matching, not instant dispatch
The defining difference from ride-hailing is that Urban Company does not send the nearest available worker right now. A service is booked into a future time slot, up to a few days ahead, and it needs a specific skill. That changes the core question. In ride-hailing, the question is who is closest and free; in a services marketplace, the question is which slots can actually be fulfilled and which professional should take a scheduled job. Urban Company offers 24 slots a day up to 3 days ahead, about 72 slots, and the key insight it published is that showing a slot is a promise: if you offer a slot that no professional will accept, you get a booking that cannot be fulfilled, which is a worse experience than not offering it. So the system must decide, before showing a slot, whether it is realistically fulfillable. That reframes matching from a routing problem into a prediction problem, which is the heart of the design.
Lead Score and Request Score
Urban Company's published answer to which slots to show and whom to route to rests on two predictions. The Lead Score is the machine-learned probability that a specific professional will accept a specific request, a lead being the notification sent to a professional with the details to accept or decline. The Request Score is the probability that at least one eligible, available professional will accept a request for a given slot, computed from the Lead Scores of the candidates for that slot. The Request Score is what gates the slot: if it is high enough, the slot is safe to show; if not, offering it risks a booking no one takes. Because a customer session spans many slots, many candidate professionals per slot, and several days, the system scores on the order of 1,100 combinations per session, roughly 24 slots by 15 providers by 3 days, which is why the scoring must be fast and runs in a dedicated matching service. This two-level design, predict per-professional acceptance, then aggregate to a per-slot fulfillability, is the clean idea to carry into an interview.
The matching model and its signals
The Lead Score is produced by a gradient-boosted model, which Urban Company reported training and tuning on managed cloud machine-learning infrastructure across many service supercategories with a couple of dozen engineered features, and importantly it is calibrated, so a predicted 0.5 acceptance probability really means about half of such leads are accepted, which matters because the scores are compared and thresholded. The signals are what you would reason about from first principles and Urban Company confirmed: category skill, since a professional trained for one service should not be sent for another, location proximity within the hyperlocal micro-market, using the professional's recent location history relative to the customer, availability state, whether the professional is on a job, at home, or offline, and their history of accepting work. Filtering on these happens before a lead is ever sent, so not every eligible professional sees every request; the request goes to those most likely to accept and deliver. The lesson is that good matching here is skill-and-acceptance aware, not distance-first.
Optimizing reliability as a trade-off
Urban Company frames the objective not as speed but as reliability, and it makes the trade-off explicit. There are two failure modes. A No-Response request is one where a slot was shown and a booking made, but no professional accepted, which is a broken promise to the customer. A Requests-Lost outcome is the opposite error: being so cautious about fulfillability that you block or hide a request that actually could have been served, losing good business. These pull against each other, since the safest way to avoid no-responses is to show fewer slots, which loses requests. Urban Company reported using causal modeling to balance them, with a guiding rule that blocking a likely-bad request must not cost more than one good request, and reported that no-response rates fell after rolling this out. This is a mature way to think about a marketplace: define the two errors, quantify their relative cost, and tune the system to the right point between them, rather than chasing a single metric like coverage or speed.
Managed, trained supply as part of the system
Unlike an open marketplace that lists whoever signs up, Urban Company treats its supply as a managed asset. It onboards, trains, and certifies professionals at scale, with a large training footprint of trainers and classrooms, and progresses them through quality tiers, and it reported that repeat professionals account for the large majority of its transaction value, so retaining and developing good professionals is central. This matters for the design because supply quality and availability are inside the platform, not external givens. The matching system can rely on professionals being certified for the skills they are matched to, the tier and rating of a professional feed into who gets which requests, and the acceptance-history signal is meaningful because the same professionals stay on the platform. The interview point is that the business-model choice, curated supply rather than an open pool, flows directly into the systems: training, certification, tiers, and ratings become first-class components that a pure open marketplace would not build.
Hyperlocal structure and the serving platform
Two more pieces round out the design. First, geography: Urban Company divides its 51 cities into more than 12,000 micro-markets of roughly 3 to 5 kilometers, so matching is localized, a customer is served by professionals in their micro-market, which keeps travel reasonable for a scheduled visit and makes the candidate set for scoring small and relevant. Second, the platform: Urban Company described a separate matchmaking service, an event-driven architecture using Kafka to connect microservices asynchronously as it moved off a monolith, Redis for caching, job scheduling, and listing professionals, and a data pipeline feeding analytics and the models, on cloud infrastructure. The separation of the matchmaking service is notable, because the scoring workload is heavy and specialized and benefits from being isolated and scaled on its own. Some of this stack description is from Urban Company's earlier writing, so it is directionally accurate, while the matching and reliability posts are the more recent and load-bearing sources.
Trade-offs to discuss
Every senior interviewer expects you to surface at least 3 of these. Pick the decisions, state the alternatives, and justify your choice.
Scheduled slot matching versus instant nearest-worker dispatch
Instant dispatch is simpler and works when the service is immediate and interchangeable, like a ride. Home services are scheduled and skill-specific, so the system instead books future slots and must predict fulfillability, which is more complex but fits the product. The cost is the whole prediction and scoring apparatus, accepted because showing an unfulfillable slot is a broken promise, and reliability, not speed, is what customers value here.
Gating slots by predicted acceptance versus showing all slots
Showing every theoretical slot maximizes apparent choice but leads to bookings no professional accepts, which is a bad experience. Gating slots by a Request Score shows only those likely to be fulfilled, improving reliability, at the cost of offering fewer slots and the risk of hiding a slot that could have worked. Urban Company manages that risk explicitly with the no-response versus requests-lost trade-off rather than defaulting to showing everything.
Managed, trained supply versus an open marketplace pool
An open pool is asset-light and scales sign-ups easily, but it gives up control over skill and quality, which is unacceptable when a professional enters a customer's home for a skilled service. Urban Company trains and certifies its supply and manages tiers and ratings, which raises quality and makes matching signals reliable, at the cost of running training and certification at scale. The repeat-professional economics show the investment paying back.
Optimizing the no-response versus requests-lost balance versus a single metric
Optimizing one metric, say coverage or booking speed, is simpler but pushes the system into an extreme, either promising slots it cannot keep or being so cautious it loses business. Explicitly modeling the two errors and their relative cost, and tuning to the balance point, gives a healthier marketplace. The cost is the causal modeling and careful measurement required, accepted because the two errors trade against each other and neither can be ignored.
A separate matchmaking service versus matching inside the monolith
Keeping matching in the main application is simpler at first, but the scoring workload, around 1,100 predictions per session with machine-learning models, is heavy and specialized and would strain a general backend. Running matchmaking as its own service lets it be scaled and optimized independently, at the cost of another service and the event plumbing to feed it, which Urban Company adopted as it moved to microservices with Kafka.
How Urban Company actually does it
Urban Company's matching and reliability engineering are documented on its own engineering blog, its scale and financials are reported through its 2025 IPO filings, and the serving-stack details come from its earlier engineering writing and are directionally accurate. Urban Company described its platform as a matchmaker that must find the right professional, get them to accept, and deliver quality, and it published a machine-learning system built on this: a Lead Score predicting the probability a specific professional accepts a specific request, and a Request Score predicting whether at least one eligible available professional will accept a slot, which gates whether a slot is shown. It offers 24 slots a day up to 3 days ahead, about 72 slots, and scores on the order of 1,100 professional-and-slot combinations per customer session, using a gradient-boosted model trained and tuned on managed cloud machine-learning infrastructure across many supercategories with calibrated outputs, filtering candidates by skill, location proximity, availability state, and acceptance history. It frames the objective as reliability, balancing no-response requests against lost good requests with causal modeling, and reported reduced no-response rates after rollout. It described a separate matchmaking service, an event-driven architecture using Kafka, Redis for caching, scheduling, and listing professionals, and a data pipeline, on cloud infrastructure. On scale, Urban Company reported about 6.8 million annual transacting customers and about 47,888 average monthly active service partners in FY25, across 51 cities divided into more than 12,000 micro-markets, with revenue of about 1,144 crore rupees, turning profitable, and it manages a trained, certified workforce with quality tiers where repeat professionals drive most transaction value. Three accuracy notes for the interview. First, Urban Company has not published a total gross transaction value figure or a clean per-year job count, so do not quote those. Second, the stack details are from its older engineering posts and should be treated as directional, while the matching and reliability posts are the recent, load-bearing sources. Third, demand forecasting and dynamic pricing are not published Urban Company systems and are the general marketplace pattern rather than stated facts.
Sources
- Urban Company Engineering, How Urban Company uses machine learning to improve reliability of the marketplace: Lead Score, Request Score, slot gating, and the no-response versus requests-lost trade-off
- Urban Company Engineering, How To: events infrastructure: the Kafka event-driven microservice architecture
- Urban Company Engineering, UrbanClap Tech World: the overall stack, the separate matchmaking service, Redis, and the data platform (older)
- MediaNama, Urban Company returns to profit in FY25: about 6.8 million customers and 47,888 monthly active partners
- Mehta Equities Urban Company IPO note: FY23 to FY25 financials, 51 cities, and 12,000-plus micro-markets, from the offer document
- Urban Company Investor Relations, FY24 annual business summary: revenue, the training footprint, and partner earnings
Lessons to study before this interview
If any of these topics are fuzzy, the interviewer will catch it. Each lesson is 15 to 60 minutes with diagrams, code, and a quiz.
Geospatial Indexing
intermediate / database types storage
Cache-Aside Pattern
foundation / caching strategies
Message Queues
intermediate / messaging event systems
Database Sharding
foundation / database fundamentals
Load Balancing
foundation / core fundamentals
High Availability
advanced / reliability resilience
Rate Limiting for Resilience
advanced / reliability resilience