Classic design · Mid
Event recommendation
Classic interview design. Key points: learning to rank, geo/time features, and cold start for ephemeral items.
Short answer
Classic interview design. Key points: learning to rank, geo/time features, and cold start for ephemeral items. The interview script starts from an event recommendation system similar to Eventbrite's, in the context of ML systems design. The business goal is to increase ticket sales, with personalized recommendations for each user, free or paid events, and users worldwide, in several languages.
01 · CONTEXT AND GOAL
What it means to recommend an event
The interview script starts from an event recommendation system similar to Eventbrite's, in the context of ML systems design. The business goal is to increase ticket sales, with personalized recommendations for each user, free or paid events, and users worldwide, in several languages.
For sizing, the script assumes a hundred million daily active users and one million events per month, and suggests a latency of 200 ms (in the script, with a question mark).
As an ML problem, the goal is to recommend the most relevant events to maximize the number of registered events. The category is a recommendation system with a ranking approach: the user identifier goes in and an ordered list of events with a relevance score comes out.
The script lists three learning-to-rank formulations, pointwise, pairwise, and listwise, and picks pointwise. In it the input is the user-event pair and the output is the probability of registration, a binary classification.
02 · DATA AND EPHEMERAL ITEMS
Few signals per event, a lot of feature engineering
The script's data sources include the user, with profile and historical interactions, friendships between users, and user-event interactions. The script also asks, in the initial clarification, whether friendships between users can be used.
The script states that recommending events is harder than recommending movies or videos: the event is short-lived, so it accumulates few historical interactions, which leads to cold start, described as a constant new-item problem. The script's answer is to invest more effort in feature engineering, with many meaningful features.
03 · GEO, TIME, AND SOCIAL FEATURES
Four groups of features
| Grupo | Examples cited in the script |
|---|---|
| User | Age, gender, and event history |
| Evento | Price and number of registrants; time, duration, and time remaining; location (city, country, accessibility); host and their popularity |
| User and event | Similarity of price, description, and time (duration, day, hour of day); same city, state, or country |
| Social | Number or share of friends attending; invitations from friends; event organized by a friend |
In preprocessing, the script uses bucketization with one-hot for age, distance, and time. Location and distance features call for efficient computation, and the script separates batch processing, for what is static, from online stream processing, for what is dynamic (data pipelines, real-time analytics).
As an evolution, the script cites learning embeddings for users and events.
04 · TWO-STAGE FUNNEL
Filter by rules, then rank
The script's MVP architecture is a two-stage funnel. The first generates candidates by rule-based event filtering, such as location, and reduces the set from millions of events to hundreds. The second is ranking, a pointwise binary classifier that scores the user-event pairs and sorts them.
The app asks the recommendation service for the list for the user: the user identifier goes in and an ordered list of events with relevance scores comes out.
The service triggers the candidate filter, which queries the event catalog applying attribute-based rules such as location.
Filtering reduces the set from millions of events to hundreds.
To score each pair, the ranker reads the features from the online store, fed by batch processing of the static features and by the stream of the dynamic ones.
The ranker computes the score of the user-event pairs with a pointwise binary classifier and sorts them.
The sorted list goes back to the service and to the user's app.
05 · MODEL AND TRAINING
Baseline GBDT, neural network as an improvement
| Model | What the script says |
|---|---|
| GBDT | Good for structured data, but not for continuous learning |
| Neural network | Continuous learning, expressive, with nonlinear relationships |
The script suggests starting with GBDT as a baseline and testing the neural network as an improvement, and considers both good options.
The dataset has one row per user-event pair, with the computed features and a positive label if there was a registration and negative if not. The script mentions class imbalance and points to focal loss or class-balanced loss as the way out.
The app records user-event interactions in an event log.
The assembly process reads the interactions and the event catalog and joins the user's profile, history, and friendships.
For each user-event pair, it computes the features and writes the example with a positive label if there was a registration and negative if not.
Training reads the dataset; the script suggests starting with GBDT and experimenting with a neural network.
The trained model is stored and made available for the ranker to use in serving.
06 · METRICS
How to know whether it worked
| Tipo | Metrics cited |
|---|---|
| Offline | Precision and recall at k, which do not account for ranking quality; mAP, because registration is binary relevance |
| Online | CTR, conversion rate, favorite or like rate, and revenue gain |
Frequently asked questions
What is Event recommendation?
Classic interview design. Key points: learning to rank, geo/time features, and cold start for ephemeral items.
What does the Event recommendation design cover?
It is organized in these sections: What it means to recommend an event, Few signals per event, a lot of feature engineering, Four groups of features, Filter by rules, then rank, Baseline GBDT, neural network as an improvement, and How to know whether it worked.
How long is Event recommendation and what level is it?
It takes about 14 minutes to read and is rated Mid level.
Now design it yourself
Run this case as an interview in the System Design school: you make the decisions, the tutor challenges them and you see how your design scores.