A recommendation engine that learns from booking history, gives new listings a fair chance from day one, and only suggests what is available for the searched dates.

- Machine Learning Specialization · Coursera
- Unsupervised Learning, Recommenders, Reinforcement Learning · DeepLearning.AI & Stanford Online · Coursera
Overview
What this is and why it matters, in plain English.
A recommendation engine that learns from booking history, gives new listings a fair chance from day one, and only suggests what is available for the searched dates.
Personal suggestions for the next vehicle or property a renter is likely to book, including brand-new listings.
The situation
What was going on before, and why it needed fixing.
The rental listing page showed the same popular assets to every visitor. New listings rarely surfaced, and returning renters started every search from scratch.
The listing page showed the same popular assets to everyone. New listings never surfaced, and repeat renters had to search from scratch each time.
What it needed to do
The outcomes the project had to deliver.
- Personalize suggestions from booking history.
- Give new listings a fair chance before they have bookings.
- Never suggest something unavailable for the searched dates.
What I did
My part of the work and who I worked with.
I designed the recommender: collaborative filtering and content-based models in TensorFlow and NumPy, the blending and availability filter, and the Redis serving layer consumed by the Laravel front end on AWS.
How it works
The main building blocks, from the screen people use to the data underneath.
Trained a collaborative filtering model on implicit booking signals, added a content-based model on listing features for cold-start items, and blended both into a ranked list cached per user in Redis for the Laravel front end.
- 01
Interaction data
Views and bookings are turned into implicit feedback, with bookings weighted above views.
- 02
Collaborative filtering
Learns user and item vectors from interactions to find assets similar renters booked.
- 03
Content-based model
Two neural towers map user and listing features into the same space, so new listings can be scored from their attributes.
- 04
Blend and serve
Scores are blended, filtered by availability, and cached per user in Redis for the Laravel listing page.
Key choices and trade-offs
Every build involves trade-offs. These are the important ones and what each one cost.
| Decision | Trade-off |
|---|---|
| Blend two models instead of choosing one. | More moving parts, but both returning renters and new listings are covered. |
| Precompute suggestions. | Suggestions are refreshed in batch rather than instantly, but page loads read straight from Redis. |
| Availability filter at serve time. | A small extra step per request, but no suggestion is ever unbookable. |
Under the hood
Implementation details for technical readers, with a code sample.
- Applies collaborative filtering and content-based filtering with neural networks from Unsupervised Learning, Recommenders, Reinforcement Learning.
- Uses the TensorFlow modeling practices from the Machine Learning Specialization.
- A cold-start path so new listings surface from day one.
user_in = tf.keras.Input(shape=(num_user_features,))
item_in = tf.keras.Input(shape=(num_item_features,))
user_vec = tf.linalg.l2_normalize(user_tower(user_in), axis=1)
item_vec = tf.linalg.l2_normalize(item_tower(item_in), axis=1)
score = tf.keras.layers.Dot(axes=1)([user_vec, item_vec])
model = tf.keras.Model([user_in, item_in], score)
model.compile(optimizer=tf.keras.optimizers.Adam(1e-3), loss="mse")Problems solved
What got in the way, and how each problem was fixed.
- 01
New listings have no bookings, so the content model carries them until real interactions arrive.
The content-based model scores new listings from their features until enough interactions arrive for collaborative filtering.
- 02
Booking data is implicit feedback; views and bookings had to be weighted differently instead of treated as ratings.
Bookings and views weighted as implicit signals, with mean normalization so heavy users do not dominate.
- 03
Suggestions must never include assets that are unavailable for the dates the renter searched.
Availability checked against the booking calendar before suggestions are returned.
Security, speed and growth
How data is protected, and how the system stays fast as usage grows.
Security
Models train on interaction IDs and listing features, not personal details. Suggestions are cached per user under keys only that user’s session can read.
Speed & growth
Suggestions are precomputed and served from Redis, so the listing page adds no model latency.
Quality and releases
How changes were tested and shipped safely.
Offline ranking evaluation on held-out interactions, cold-start checks with listings removed from training, and availability tests on suggested items.
Tech stack
The tools and technologies used, for recruiters and technical reviewers.
Results
What the system is designed to achieve, and how.
| Metric | Result |
|---|---|
| Models | 2 blended |
| Cold start | content fallback |
| Serving | Redis precomputed |
These are design targets and approach choices for the system, not reported production figures.
Questions
Plain answers first, then the detail a technical reviewer would ask about.
Common questions
- What does a renter see?
- Suggestions based on what similar renters booked, filtered to listings that are actually available for their dates.
- Do new listings get a chance?
- Yes. New listings are matched on their features until they have booking history of their own.
For your tech lead
- Which certification does this apply?
- Unsupervised Learning, Recommenders, Reinforcement Learning, plus the Machine Learning Specialization.
- How do new listings get recommended?
- A content-based model scores them from their attributes until they have bookings.
Key takeaways
- •Personal suggestions for the next vehicle or property a renter is likely to book, including brand-new listings.
- •Built with Python, TensorFlow, NumPy, Laravel, Redis, AWS.