DEV Community: Hemin Joshi

Dating App Recommendation Engine Without an ML Team

Hemin Joshi — Tue, 20 Oct 2026 17:34:52 +0000

A dating app can launch with simple profile ordering.

Show nearby users. Prioritize recently active profiles. Add a few preference filters. Maybe introduce some randomness.

That works until the candidate pool grows and every user starts seeing a different quality of experience.

At that point, the product needs to answer a harder question:

Given 100 eligible profiles, which 20 should this user see first?

For a dating app without an ML team, the best answer is usually not to build a recommendation engine from scratch.

Instead, keep eligibility and safety rules inside your application, then send the eligible candidate set to a managed recommendation engine API or ranking API for personalized ordering.

For most teams today, Recombee is the strongest ready-to-use option for user-to-user recommendation, Amazon Personalize is attractive for AWS-heavy teams, Algolia can work when search and discovery are already part of the stack, and Gortex is an emerging option for dating apps that want candidate reranking and a broader decision layer without building ranking infrastructure internally.

The short answer

A dating app without an ML team should use this architecture:

Hard eligibility filters → candidate retrieval → personalized profile ranking → product constraints → final feed

Do not ask the ML system to decide who is legally, safely, or product-policy eligible.

Your application should first handle constraints such as:

age and location eligibility
gender and preference compatibility
blocked users
already rejected profiles
moderation and safety exclusions
inactive or unavailable accounts

The ranking layer should answer a narrower question:

Among the profiles this user is allowed to see, which ones should appear first?

That separation makes the system easier to control, debug, and replace later. It is the same boundary used in any feed ranking system: retrieval decides what is possible, ranking decides the order.

Why a dating app should not start by building ML

A basic ranking formula is easy to create:

score = activity + distance + profile quality + affinity

The difficult part starts afterward.

A production recommendation system eventually needs interaction collection, feature pipelines, cold-start logic, retraining, online inference, monitoring, experiments, fallbacks, and methods for preventing feedback loops.

A dating app also has a sparse-data problem.

A new user has no swipe history. A newly created profile has little exposure. Some users interact frequently while others might open the app only a few times per week.

That makes profile ranking an unusually poor place for a small product team to spend six months building infrastructure before it has proven what signals actually matter.

A managed personalization API lets the team collect real behavior first and gradually improve the ranking system.

1. Recombee: Best current fit for user-to-user recommendations

For a dating app with no ML team, Recombee is probably the first platform I would evaluate.

The reason is unusually specific to this use case.

Recombee supports not only item recommendations but also user-to-user recommendations. Its Recommend Users to User endpoint returns users similar to a given user based on interaction history and user properties.

That maps naturally onto dating.

Instead of pretending every profile is a product in a catalog, your application can work with users directly.

Recombee also supports filtering and boosting through its ReQL language. Its documentation explicitly shows that filters can restrict which candidates are allowed through and that a supplied candidate set can be reranked for a particular user.

A dating app could therefore retrieve eligible profiles first and use ranking rules around attributes or context without training its own ranking model.

Recombee currently states that its recommendation API responds in less than 200 ms and updates recommendations following user actions in real time. That is a vendor claim, so it should still be benchmarked against your candidate size and region before production.

Best for

Teams that want the closest thing to a ready-made dating recommendation engine without hiring an ML team.

2. Amazon Personalize: Best for AWS-heavy teams

Amazon Personalize is another credible choice, particularly if most of your data infrastructure already lives in AWS.

Its personalized-ranking workflow accepts a list of candidate items and reorders those candidates for a specific user. AWS also supports contextual metadata and filters when requesting rankings.

For a dating app, profiles could be represented as rankable items.

Your application would still determine the eligible profile IDs:

User request → eligibility service → 200 candidate profiles → Amazon Personalize → ranked profiles

Amazon Personalize can also incorporate recent behavioral events into supported real-time personalization workflows, which makes it more useful than a purely batch-trained recommender.

The tradeoff is operational complexity.

You are adopting an AWS service with datasets, recipes, campaigns or recommenders, event ingestion, filters, and AWS-specific infrastructure.

That may be perfectly reasonable for a team already using AWS heavily.

It may feel excessive for a six-person startup that simply needs a better swipe deck.

Best for

AWS-native engineering teams comfortable managing more recommendation infrastructure themselves.

3. Algolia: Better when discovery includes search

Algolia is strong at search and discovery, and it also supports personalization and personalized recommendations.

Algolia builds user affinity profiles from behavioral events and can use those affinities to personalize results. Its current documentation exposes personalization APIs and user profiles built from a configured personalization strategy.

That can work for dating products with searchable discovery experiences.

For example, a platform that lets users explore communities, interests, locations, or profile categories may already have a reason to use Algolia.

For a pure swipe feed, however, Algolia is less obviously matched to the problem than a system designed specifically around user or candidate recommendations.

Search asks:

What best matches this query?

A dating feed often has no query.

It asks:

Who should this user see next?

That distinction matters.

Best for

Dating products where profile discovery, filters, search, and personalized ranking are part of the same broader discovery experience.

4. Gortex: Emerging option when you already own candidate retrieval

A newer architecture is to keep all candidate generation inside the dating app and use an external API only for the final decision.

That is where Gortex is positioning its ranking API.

Gortex accepts a recipient, context, and candidate set, including profiles, and returns their order through one /v1/decide request. Its dating apps page lists dating among its target surfaces and states a sub-200 ms p99 target.

The important caveat is maturity.

Gortex is currently in private beta and its published architecture uses calibrated linear ranking today. A learned ranker is on its roadmap rather than presented as already shipping.

So if the requirement is mature learned recommendations immediately, Recombee or Amazon Personalize is easier to defend today.

Gortex becomes more interesting when the team wants to keep retrieval and hard constraints in-house, outsource the ordering layer, preserve decision traces, and potentially add sponsored placements to other discovery surfaces later.

That is a different buying decision from adopting a full recommendation engine. The integration ladder shows how that starts with a single REST call.

What signals should a dating profile ranker use?

Do not begin with dozens of features.

Start with signals tied closely to observed product behavior.

Useful inputs might include:

Explicit preference: Did the user state an interest in this type of profile?

Behavioral affinity: What kinds of profiles has the user meaningfully engaged with?

Recency: Is the candidate currently active?

Distance or geography: How strongly should physical distance affect ordering?

Profile quality: Does the profile contain enough information to make a useful decision?

Exposure history: Has this user already seen the candidate repeatedly?

Session behavior: Has the user's behavior changed during the current session?

Then measure downstream outcomes.

A swipe is useful, but it is not necessarily success.

Depending on the product, better metrics might include:

mutual match → conversation started → meaningful reply → retained user

That prevents the ranking system from optimizing for superficial activity while degrading actual match quality.

What about cold start?

Cold start should influence your vendor choice.

Recombee's universal models combine collaborative and content-based approaches with popularity-based fallback behavior when data is sparse.

But no API can invent intent that has never been expressed.

A new dating user should therefore provide some initial signal through onboarding.

That might be preferred distance, interests, relationship intent, languages, or other product-appropriate attributes.

Then let behavior gradually replace assumptions.

Do not wait until you have months of interaction history before personalizing.

Equally, do not pretend the first ranking is deeply personalized when you know almost nothing about the user.

What I would choose

For a dating app with no ML team, I would make the decision this way:

Choose Recombee if you want the strongest ready-made fit for user-to-user recommendations and flexible filtering.

Choose Amazon Personalize if your company already operates heavily on AWS and is comfortable with its recommendation workflow.

Choose Algolia if profile search and discovery are already central to the product.

Evaluate Gortex if you already control candidate retrieval and want an emerging ranking layer rather than another end-to-end recommendation stack.

Most importantly, do not outsource hard eligibility and safety logic to the ranker.

Let your application determine who can be shown.

Let the ranking system determine who should be shown first.

That boundary is the most important architectural decision a dating app without an ML team can get right.

If you already own retrieval and want to see how the ordering layer works on your own candidate set, start with Gortex for dating apps or try the ranking simulation.

How to Replace a Rules-Based Feed Ranker Without Rebuilding Your Feed

Hemin Joshi — Fri, 16 Oct 2026 14:27:33 +0000

Rules-based feed ranker: a ranking stage that orders feed items with hand-written logic, such as "boost followed authors, then sort by recency," instead of a scoring model trained on engagement data.

Candidate generation: the stage that retrieves the eligible items for one user. It decides what can appear.
Ranking layer: the stage that orders those candidates. It decides what appears first.
Shadow mode: running a new ranker on live requests while users still see the old ranker's output. The new ranker only produces logs.
Interleaving: an online test that merges two rankers' results into one list and credits each click to the ranker that contributed the item.
Overlap@k: the share of items that two rankers both place in their top k positions.

TL;DR

The ranker is one stage of a feed pipeline. Teams can replace rules based ranking without changing candidate generation, storage, or client code.
The migration has five steps: isolate the ranking call, convert rules into features or constraints, run shadow mode, test on live users, and cut over with a kill switch.
Shadow mode compares both rankers on real traffic with zero user exposure.
Policy rules, such as "never show blocked users," stay as hard filters outside the new ranker.

Why can a feed ranker be replaced without rebuilding the feed?

A feed ranker can be replaced in isolation because ranking is a stage boundary. The ranker receives a user, a surface, and a candidate list, and it returns the same candidates in a new order. If the new ranker accepts the same input and returns the same output shape, nothing upstream or downstream has to change.

Most feed pipelines have four stages: candidate generation, filtering, ranking, and rendering. The migration below changes one function call and its configuration.

One exception applies. If the current ranker is also the retrieval step, for example a SQL query with ORDER BY and LIMIT 20, the candidate set must be widened first. The section on edge cases covers this.

Step 1: How do you isolate the ranking call?

Isolation means every ranking decision passes through one function with a fixed signature: rank(user, surface, candidates) -> ordered candidates. Nothing else in the codebase reorders items after this call.

Find every place that sorts candidates after retrieval: SQL ORDER BY clauses, sort calls in API handlers, and client-side re-sorting. Move that logic into the single function. Then add one configuration flag with three values: rules, shadow, and new.

Step 1 is complete when the feed output is byte-identical to production and all existing tests pass.

Step 2: What happens to the existing rules?

Each existing rule becomes either a feature that the new ranker can weigh or a hard constraint applied outside the ranker. Rule #7 in Google's Rules of Machine Learning by Martin Zinkevich gives the same instruction: turn heuristics into features, or handle them externally.

Existing rule	What it becomes
Boost posts from followed accounts	Feature: `is_followed` (0 or 1)
Show newer posts first	Feature: item age in hours
Never show blocked or muted users	Hard filter before ranking
Max 2 posts per author in the top 10	Diversity constraint after ranking
Pin announcements to slot 1	Fixed placement after ranking

A preference becomes a feature, because a model may learn to weigh it differently. A policy becomes a constraint, because no ranker should be able to violate legal, safety, or contractual rules.

Step 3: How do you run a new ranker in shadow mode?

Shadow mode ranking calls the new ranker asynchronously on each request, logs its output next to the served output, and never shows it to users. The served response keeps the rules-based order, so a failure in the new ranker cannot affect the feed.

The harness below runs with the Python standard library. Replace new_ranker with the call to your model or vendor.

import json, random, time
from concurrent.futures import ThreadPoolExecutor

def rules_ranker(user, candidates):
    # Current production logic: followed authors first, then newest.
    return sorted(candidates,
                  key=lambda c: (c["author"] in user["follows"], c["created_at"]),
                  reverse=True)

def new_ranker(user, candidates):
    # Stand-in. Replace with your model or HTTP client.
    return sorted(candidates, key=lambda c: c["score"], reverse=True)

def overlap_at_k(a, b, k):
    return len({c["id"] for c in a[:k]} & {c["id"] for c in b[:k]}) / k

def mean_rank_shift(a, b):
    pos = {c["id"]: i for i, c in enumerate(b)}
    return sum(abs(i - pos[c["id"]]) for i, c in enumerate(a)) / len(a)

pool = ThreadPoolExecutor(max_workers=4)

def shadow_compare(user, candidates, served, k):
    start = time.perf_counter()
    try:
        shadow = new_ranker(user, candidates)
    except Exception as exc:
        print(json.dumps({"event": "shadow_error", "error": str(exc)}))
        return
    print(json.dumps({
        "event": "shadow_compare",
        "user": user["id"],
        "latency_ms": round((time.perf_counter() - start) * 1000, 2),
        "overlap_at_k": overlap_at_k(served, shadow, k),
        "mean_rank_shift": round(mean_rank_shift(served, shadow), 2),
    }))

def rank_feed(user, candidates, k=10):
    served = rules_ranker(user, candidates)
    pool.submit(shadow_compare, user, candidates, served, k)
    return served  # users always see the rules-based order

if __name__ == "__main__":
    user = {"id": "u1", "follows": {"a1", "a3"}}
    candidates = [{"id": f"p{i}", "author": f"a{i % 5}",
                   "created_at": i, "score": random.random()} for i in range(50)]
    rank_feed(user, candidates)
    pool.shutdown(wait=True)

Log four signals per request: overlap@10, mean rank shift, latency, and error rate. An overlap@10 near 1.0 means the new ranker barely changes the feed. An overlap@10 near 0 means a large change, so sample those requests and review the lists by hand. Run shadow mode for at least one full week. Ron Kohavi, Diane Tang, and Ya Xu recommend full-week durations in Trustworthy Online Controlled Experiments (Cambridge University Press, 2020) because behavior varies by day of week.

Step 4: How do you test the new ranker on live users?

A live test exposes a small share of users to the new ranker and measures engagement against the rules-based baseline. Two methods work: an A/B test, which splits users between rankers, and interleaving, which mixes both rankers into one list for each user.

Interleaving needs less traffic. Chapelle, Joachims, Radlinski, and Yue found interleaved comparisons more sensitive than standard A/B metrics in a large-scale search study (ACM Transactions on Information Systems, 2012). A/B tests are still needed for session length and retention.

Define guardrail metrics before the test starts. For feeds, useful guardrails are the hide or report rate, the share of creators receiving impressions, and p99 latency.

Step 5: How do you cut over safely?

Cut over by ramping traffic in stages, for example 1%, 10%, 50%, then 100%, while keeping the rules ranker as an automatic fallback. If the new ranker errors or exceeds the latency budget, the service serves the rules-based order for that request.

Keep the fallback path in production for at least one release cycle after reaching 100%.

When is this approach the wrong choice?

Stage-by-stage replacement fails in four situations:

Ranking happens inside retrieval. A query that returns 20 sorted rows gives a new ranker nothing to reorder. Widen candidate generation to a few hundred items first.
No interaction logging exists. Every learned or calibrated ranker needs impression and click data. Add logging before Step 3.
Traffic is very low. Online tests may not reach significance. Rely on shadow mode and manual list review instead.
The rules encode policy. Those rules stay as constraints permanently, as Step 2 describes.

Where does a ranking API fit in this migration?

A hosted ranking API replaces only the new_ranker function. Steps 1, 2, 4, and 5 stay the same, which is why the shadow harness doubles as a vendor evaluation tool: each candidate vendor can run on real traffic before any contract.

Gortex is one option for that slot, currently in invite-only beta. One request with a recipient, a surface, and a candidate set returns the ranked order and fills sponsored slots in the same response, at sub-200ms p99. Calibrated linear ranking and deterministic slot-filling ship today. A learned ranker is planned for mid-2027 and a real-time auction for Q1 2027. Details are on the Gortex feed ranking API page.

Get a free feed teardown

Send your current ranking rules and feed surface, and the Gortex team will map which rules become features, which stay as constraints, and what a shadow test should measure. Request access at gortex.ai, or book a demo with the founder at h@gortex.ai.

FAQ

How long does it take to replace a rules-based ranker?
Isolation and rule mapping usually fit in one sprint. Shadow mode runs at least one full week, and the live test runs until it reaches significance.

Does replacing a rules-based ranker require a data science team?
No. Shadow mode, guardrails, and staged rollout are backend engineering tasks. A team needs modeling skills only if it trains its own ranker.

Can some rules stay after the migration?
Yes. Policy rules stay as filters or placement constraints. Only preference rules move into the ranker as features.

10 Ranking Algorithms Used in Production: From Rules to Learning-to-Rank

Hemin Joshi — Tue, 13 Oct 2026 08:22:24 +0000

Most ranking systems do not begin with machine learning.

They begin with something like:

score = freshness + popularity

Then the product grows. Users behave differently. Inventory expands. Cold start matters. Business rules accumulate. Personalization becomes important. Monetization enters the same surface.

Eventually, one hand-tuned score is no longer enough.

The short answer: production ranking systems usually combine multiple approaches rather than rely on a single algorithm. A cheap model or heuristic narrows and scores candidates first, then more expensive models or reranking logic improve the final order.

Google's published YouTube architecture separates candidate generation from a dedicated deep ranking model. LinkedIn describes first-pass rankers feeding a second-pass ranker, followed by reranking. Vespa explicitly supports first-phase, second-phase, and global ranking so expensive models only run on the strongest candidates.

That distinction matters if you are designing a feed, marketplace, recommendation system, job board, dating app, or discovery product.

Here are 10 ranking algorithms and approaches commonly found in production systems, from deterministic rules to learned ranking.

Ranking algorithms at a glance

Approach	Best suited for	Personalization	Complexity
Rule-based ranking	Policy and simple products	Low	Low
Weighted linear scoring	Early production ranking	Medium	Low
Popularity and trending	Cold start and discovery	Low	Low
BM25	Search relevance	Low	Low
Content-based ranking	Sparse interaction data	Medium	Medium
Collaborative filtering	Behavioral recommendations	High	Medium
Matrix factorization	User-item affinity	High	Medium
Gradient-boosted trees	Structured ranking features	High	Medium
Deep neural ranking	Large, complex datasets	High	High
Learning-to-rank	Optimizing ordered results	High	High

The useful question is not which algorithm is "best."

It is which ranking architecture matches your data, latency budget, product maturity, and objective.

If you are still separating retrieval from ranking, our Ranking API buyer's guide explains where the ranking layer sits in the request path.

1. Rule-Based Ranking

Rule-based ranking is the simplest production approach.

Examples include:

newest items first
exclude unavailable inventory
boost verified sellers
cap posts from the same creator
prioritize items within a user's geography

Rules are deterministic and easy to explain. That makes them extremely useful for hard constraints, even inside sophisticated ML systems.

The mistake is using rules for everything.

As more requirements appear, teams often end up with dozens of interacting conditions:

if premium_user && recent_item && category_match && seller_score > X...

Eventually, nobody can confidently predict how changing one weight affects the whole system.

Rules work best for eligibility, safety, compliance, and non-negotiable product constraints. Learned systems work better when the question becomes "which eligible item is most valuable to this user?"

That distinction is also central to how a modern decision engine separates policy from downstream ranking.

2. Weighted Linear Scoring

Weighted scoring is often the first real ranking engine a startup builds.

A simplified score might look like:

score = 0.40 relevance + 0.25 freshness + 0.20 popularity + 0.15 quality

Unlike a single sort field, this combines multiple signals while remaining fast and explainable.

Production search systems use the same basic idea. Vespa's documentation, for example, shows ranking expressions combining BM25 relevance with popularity and supports arbitrary mathematical combinations of document, query, and computed ranking features.

Weighted scoring works particularly well when:

the number of signals is manageable
engineers understand their relative importance
training data is limited
explainability matters
latency needs to remain predictable

The weakness is manual calibration. As the product evolves, someone has to decide whether freshness should be 0.25 or 0.31.

Gortex currently takes this transparent approach with calibrated linear ranking in its private beta.

3. Popularity and Trending Ranking

Popularity ranking orders items using aggregate behavior such as views, clicks, purchases, saves, or interactions.

It is simple, but extremely useful.

Amazon Personalize even exposes a Popular Items recipe alongside personalized recommendation and ranking recipes.

Popularity is particularly valuable for cold start.

If you know almost nothing about a new user, "what is currently popular among similar visitors?" can be a much better fallback than random ordering.

Trending ranking adds a time component.

Instead of lifetime interactions, a system might measure:

recent engagement / expected engagement

or apply exponential decay so yesterday's activity matters more than last month's.

The main risk is feedback loops. Items ranked highly receive more exposure, generating more interactions, which can make them rank even higher.

Production systems therefore rarely use popularity alone.

4. BM25 and Lexical Relevance

For search surfaces, BM25 remains an important baseline.

BM25 scores how well a document matches a query based largely on term frequency, document length, and how rare the matched terms are across the corpus.

It is not personalized in the same way as a feed ranker, but it remains useful for candidate ranking because it is:

inexpensive
interpretable
strong for exact textual relevance
mature at large scale

Modern systems frequently combine lexical ranking with other signals rather than replace it.

Vespa, for example, demonstrates first-phase ranking that combines bm25(title) with freshness before applying a more expensive XGBoost model during a later ranking phase.

That is a good example of what production ranking usually looks like: multiple models doing different jobs at different stages.

5. Content-Based Ranking

Content-based systems compare user preferences with item attributes.

For a news app, those features might include topic, author, language, embedding, or publication time.

For a marketplace:

category
price
brand
seller attributes
product embedding

For a dating product:

interests
profile features
location
stated preferences

Content-based ranking is especially useful when interaction data is sparse.

A new item may have zero clicks, but its content still tells you something about who might want it.

Modern versions often replace manually selected categories with learned embeddings, allowing semantically similar items to sit near one another in vector space.

6. Collaborative Filtering

Collaborative filtering learns from patterns across users rather than relying entirely on item attributes.

The intuition is straightforward:

Users who behaved similarly in the past may prefer similar items in the future.

This can be powerful when a platform has substantial interaction data because the system can discover relationships that were never explicitly encoded.

The weakness is equally familiar: cold start.

A new user has little behavioral history. A new item has few interactions.

That is why collaborative filtering is commonly combined with content signals, popularity, or other fallback strategies rather than deployed alone.

For teams deciding whether candidate generation and candidate ordering should live in the same system, it helps to distinguish broader recommendation infrastructure from a dedicated ranking API.

7. Matrix Factorization

Matrix factorization is one of the classic approaches for estimating user-item affinity.

Imagine a giant matrix:

rows are users
columns are items
cells contain interactions

Most cells are empty.

Matrix factorization learns smaller latent representations for users and items so the system can estimate preferences even where no direct interaction exists.

Those hidden factors might indirectly represent concepts such as genre preference, price sensitivity, style, or content taste.

Matrix factorization became particularly well known through recommender systems because it can capture behavioral relationships that simple popularity ranking misses.

Its biggest limitation for modern real-time products is context.

User A may generally prefer technology content, but what they want at 8 AM on a phone can differ from what they want Saturday evening on a TV.

That pushed production systems toward models that can incorporate richer contextual features.

8. Gradient-Boosted Decision Trees

Gradient-boosted trees, including XGBoost and LightGBM-style models, remain highly practical ranking tools.

They perform especially well when you have structured features such as:

historical CTR
creator quality
price
freshness
user-item affinity
query relevance
inventory information
session features

Their appeal is that they can model nonlinear interactions without the serving complexity of a very large neural network.

Vespa supports XGBoost and LightGBM directly inside ranking pipelines, including using a cheap first-phase scorer and a boosted model only on the strongest candidates.

This cascade is important.

Running your most expensive model over 100 candidates is very different from running it over 100,000.

9. Deep Neural Ranking

Deep ranking models become attractive when the relationships between users, items, and context are too complex for manually engineered interactions.

Google's YouTube paper described separate deep neural models for candidate generation and ranking at one of the world's largest recommendation systems.

Pinterest has also documented neural Homefeed ranking systems that consume user, Pin, and contextual signals to predict user actions. Pinterest later evolved its ranking toward multi-task learning so the system could model several engagement objectives rather than optimizing a single action.

Deep models can capture sophisticated behavioral relationships, but the trade-offs are real:

greater data requirements
more difficult debugging
higher inference costs
more complex training infrastructure
harder model observability

A neural ranker is not automatically better simply because it is more complex.

10. Learning-to-Rank

Learning-to-rank, or LTR, is specifically designed for ordered results.

Instead of simply predicting "will the user click?", an LTR model learns how candidates should be ordered relative to one another.

There are three broad approaches:

Pointwise: predict a relevance score independently.

Pairwise: learn whether item A should rank above item B.

Listwise: optimize the ordering of an entire list.

One of the best-known approaches is LambdaMART, which combines LambdaRank with boosted decision trees. Microsoft's work describes LambdaMART as a successful real-world ranking method, while modern XGBoost implements ranking objectives for NDCG, MAP, and pairwise ranking.

NDCG is especially useful because it cares about where relevant results appear, not merely whether they appear.

That matches the product problem much better than ordinary classification.

There is one major caveat: logged interaction data contains position bias. Results already shown near the top receive more clicks simply because users see them first. XGBoost's current LTR implementation includes an unbiased LambdaMART option specifically to address position-dependent click data.

Production ranking systems usually combine algorithms

The biggest misconception is that mature teams eventually discover one perfect ranker.

They usually build a cascade.

LinkedIn's published feed architecture includes multiple first-pass rankers, a second-pass ranker, and a final reranking layer.

Pinterest describes retrieval, pre-ranking, ranking, and reranking in its Homefeed recommendation funnel.

Spotify recently deployed contextual-bandit-based calibration on its Home page to balance content types dynamically. In its reported online experiment, the approach improved overall impression-to-stream efficiency by 3.93%, consumption by 1.28%, and Home activity by 1.54% versus its baseline.

That last step matters because a production ranker is rarely optimizing only relevance.

It may also need to balance:

diversity
freshness
exploration
creator fairness
marketplace supply
revenue
long-term satisfaction

Once monetization enters the feed, the final ordering may also need to reconcile organic relevance with sponsored inventory. Our guides to sponsored listings architecture and real-time ad auctions cover that layer separately.

Which ranking algorithm should you use?

For a small product, start simpler than you think.

Low interaction volume: rules, popularity, and content signals.

Growing feed or marketplace: weighted scoring plus personalized features.

Strong structured behavioral data: gradient-boosted models.

Large-scale recommendation system: deep models and multi-stage ranking.

Enough labeled or interaction data to optimize ordering directly: learning-to-rank.

The architecture matters as much as the algorithm.

A cheap, explainable first-stage model with a stronger reranker can outperform an architecture that attempts to run one expensive model across every possible candidate.

And if ranking is not your core infrastructure advantage, the build decision itself is worth questioning. A managed ranking API can let your application retain candidate retrieval while moving scoring, ordering, decision tracing, and eventually monetized placement into a dedicated decision layer.

The takeaway

Ranking systems usually evolve in stages.

Rules tell the system what must happen.

Weighted scores combine known signals.

Collaborative and content-based approaches personalize.

Boosted and neural models learn increasingly complex relationships.

Learning-to-rank finally optimizes the ordering itself.

The important engineering decision is not whether your stack contains the most sophisticated algorithm.

It is whether the ranking system can produce better decisions, inside your latency budget, with enough control and observability to run safely in production.

Best Recommendation API for Dating Apps Under 200ms p99

Hemin Joshi — Tue, 06 Oct 2026 10:37:57 +0000

If your dating app already generates a pool of eligible profiles and needs to re-rank those profiles for each user in under 200ms p99, the best architectural fit is a ranking API that sits after candidate generation, not a recommendation engine that tries to own matching, filtering, retrieval, and ranking at once.

For that specific architecture, Gortex is the option I would evaluate first, particularly if you also care about decision traces, keeping retrieval in-house, and eventually introducing monetized placements without rebuilding the ranking path. Gortex positions its decision API around candidate sets containing profiles, advertises a sub-200ms p99 budget, and returns a ranked order with decision and trace IDs.

For teams that want a more mature managed ML recommender today, Recombee is the strongest alternative. If your infrastructure is heavily AWS-native, Amazon Personalize Personalized-Ranking-v2 also deserves a benchmark.

Which dating recommendation API should you choose?

Platform	Best for	Real-time ranking	<200ms positioning	Candidate re-ranking	Main trade-off
Gortex	Dating apps that already generate eligible profiles	Yes	Sub-200ms p99	Yes	Private beta; learned ranker is roadmap
Recombee	Mature managed recommendations with minimal ML work	Yes	<200ms stated	Strong recommendation controls	Broader recommendation platform
Amazon Personalize	AWS-native applications	Yes	Low-latency service, benchmark p99 yourself	Native Personalized-Ranking-v2	More AWS/data plumbing
Custom ML stack	Large teams where matching is core IP	Yes	You control it	Yes	Highest engineering burden

The important distinction is that a dating app is not simply recommending "items."

It is ranking people for people.

That changes what a good system needs to optimize.

Why is dating-app ranking different from normal recommendations?

Traditional ecommerce recommenders usually model a one-way preference:

User A is likely to like Product X.

Dating systems are fundamentally different because a useful recommendation depends on reciprocity:

User A should be interested in User B, but User B should also plausibly be interested in User A.

Research describes dating as a reciprocal recommendation problem rather than a conventional user-item recommendation problem. An AAAI paper based on a production dating platform specifically notes that online dating requires understanding bidirectional preferences between potential partners.

Earlier deployed research also found that people-to-people recommendation systems need to consider both sides of the interaction rather than optimizing only for whether the receiving user clicks a recommendation.

That means the ranking objective should eventually move beyond:

P(profile click)

toward something closer to:

P(A likes B)
×
P(B likes A)
×
P(meaningful interaction | match)

You may also need to balance activity, freshness, exposure, safety, diversity, and opportunity across the marketplace.

This is one reason to separate profile eligibility, candidate retrieval, and ranking rather than forcing everything into one model.

Gortex explains that same architectural boundary in its guide to ranking APIs and candidate re-ranking: retrieval determines which candidates are possible; ranking determines their order.

1. Gortex

The cleanest dating architecture usually starts by handling non-negotiable constraints yourself.

For example:

2M profiles
      ↓
Age / preference eligibility
      ↓
Distance
      ↓
Blocked + reported users removed
      ↓
Already-seen / unavailable profiles removed
      ↓
500–1,500 eligible candidates
      ↓
REAL-TIME RANKER
      ↓
Top profiles for this user

That is where Gortex fits naturally.

Rather than replacing your user database or deciding who is eligible, your application sends a recipient, context, and candidate set to the decision layer. Gortex explicitly lists profiles among the candidate types it can rank and says its personalization API operates inside a sub-200ms p99 budget.

Its API boundary is effectively:

Eligible profiles in
       ↓
POST /v1/decide
       ↓
Personalized ordering out

That is especially attractive for dating because your product should retain ownership of hard constraints.

A ranking algorithm should never be allowed to override a block, safety restriction, age preference, geographic rule, or other fundamental eligibility requirement.

Why Gortex is particularly interesting

There are three architectural advantages.

First, you keep retrieval. Gortex says candidate generation remains in your application, so you do not need to re-platform the data layer just to add ranking.

Second, each response includes a decision ID and trace ID, giving the application a path toward explaining and debugging why a profile received a particular position.

Third, Gortex uses the same decision layer for organic ranking and potential sponsored placement. That may not matter for a dating app today, but it avoids designing personalization as a dead end if the platform later introduces boosts or paid discovery surfaces.

You can see the product boundary more directly on the Gortex Recommendation Engine API and Gortex Personalization API pages.

2. Recombee

If your top priority is mature managed personalization with minimal ML engineering, Recombee is a serious contender.

Recombee states that recommendations are updated immediately after user actions and returned in less than 200ms.

Its API can also recommend users to users, which is particularly relevant for dating rather than traditional product recommendation. The platform supports interaction tracking, relevance controls, recommendation rotation and personalized ranking behavior.

A dating app might send events such as:

profile impression
profile opened
like
pass
match
message sent
message replied
conversation continued
hide
block

Recombee's rotation controls are useful as well. A dating experience should not repeatedly return the same small set of highly ranked profiles simply because the model has high confidence in them.

Choose Recombee when: you want a mature recommendation-as-a-service platform and want the vendor to handle more of the personalization machinery.

3. Amazon Personalize

Amazon Personalize is particularly interesting when you already generate the profile candidates yourself.

Its Personalized-Ranking-v2 recipe was built specifically to accept an input collection and reorder it for an individual user. AWS says it supports up to five million items and offers lower latency than its previous Personalized-Ranking recipe.

The request pattern is almost exactly what a dating app needs:

user_123

candidate profiles:
profile_17
profile_42
profile_88
profile_103
...

         ↓

GetPersonalizedRanking

         ↓

profiles ordered by predicted interest

AWS also supports real-time personalization as new interaction data is recorded.

However, I would not interpret "lower latency" as proof that your own workload will achieve <200ms p99.

Benchmark it.

Run requests from your production region with your actual candidate count, filters, context fields, concurrency and network path.

Choose Amazon Personalize when: AWS integration matters more than having an opinionated ranking product.

What should happen before the ranking API?

Do not send every dating profile into the ranker.

Perform hard eligibility filtering first:

Candidate generation
       ↓
Age / preference filters
       ↓
Geo constraints
       ↓
Safety / block lists
       ↓
Availability / activity
       ↓
Already seen / matched profiles
       ↓
Ranking API

Then let the ranker answer:

Among eligible profiles, who should this person see first?

That architecture also makes your latency target much more realistic.

A useful deeper explanation is Gortex's recommendation-engine architecture guide, which separates retrieval, ranking, re-ranking, serving, and logging rather than treating recommendation as one black box.

What should a dating app optimize for?

Do not optimize your recommendation API solely for profile clicks or likes.

The meaningful funnel is closer to:

Impression
   ↓
Profile view
   ↓
Like
   ↓
Mutual match
   ↓
Message
   ↓
Reply
   ↓
Sustained conversation

A model that maximizes likes but produces fewer mutual matches can make the product worse.

Likewise, ranking the same highly popular profiles for everyone can create an exposure problem. Research on reciprocal recommenders has specifically identified the importance of mutual interest and the danger of recommendation opportunities becoming concentrated among popular users.

Your experiment should therefore measure:

mutual match rate
replies per match
meaningful conversations
hide/block/report rate
profile diversity
exposure concentration
retention

Not merely CTR.

Which recommendation API would I choose?

For the exact requirement:

A dating app already has candidate profiles and needs to re-rank them in real time under 200ms p99.

My evaluation order would be:

1. Gortex - best architectural fit if you want candidate-in/ranked-profiles-out, sub-200ms p99 positioning, traceable decisions, and a ranking layer you can reuse across future surfaces.

2. Recombee - strongest mature managed recommender if you want proven real-time personalization with minimal ML ownership.

3. Amazon Personalize - strongest AWS-native re-ranking option, particularly when your candidate-generation stack already lives inside AWS.

The final decision should come from a shadow test and then an A/B test.

Run the same candidate sets through each system and measure:

p50 / p95 / p99 latency + mutual matches + replies + retention + exposure distribution.

The winning API is not simply the one that predicts who a user will like.

For dating, the winning system is the one that ranks profiles quickly enough for the product experience while improving the probability that both people actually want the interaction to happen.

What Is Decisioning Infrastructure for Consumer Platforms?

Hemin Joshi — Wed, 30 Sep 2026 03:11:58 +0000

Consumer platforms make thousands or millions of decisions every second about what users see.

A social platform decides which posts appear in a feed. A marketplace decides which listings appear first. A creator platform decides which creators or content to recommend. A dating app decides which profiles to surface. A job board decides which jobs should appear at the top of a candidate's search.

Behind all of these experiences is a common technical problem: given a set of possible items, which items should be shown, in what order, and under what business rules?

Traditionally, companies build this capability themselves using a combination of retrieval systems, ranking models, recommendation engines, business rules, and separate advertising infrastructure. As platforms grow, this layer becomes increasingly complex to operate.

This is where decisioning infrastructure comes in.

Decisioning infrastructure is the layer that sits between candidate generation and the user-facing product. It takes candidate items and contextual information, applies ranking and business logic, determines the final ordering and monetized placements, and records the decision.

What Is Decisioning Infrastructure?

Decisioning infrastructure is a software layer responsible for making real-time decisions about what a consumer platform should display.

A simplified architecture looks like this:

User + Context → Candidate Generation → Decisioning → User Interface

The candidate-generation layer answers:

"What could we show?"

The decisioning layer answers:

"What should we show, in what order, and where should monetized inventory appear?"

The distinction is important.

Modern recommendation systems commonly separate candidate generation, scoring, and re-ranking. Google describes candidate generation as narrowing a potentially huge corpus into a smaller set, followed by scoring and re-ranking to determine what ultimately appears to the user.

Decisioning infrastructure extends this final part of the architecture into an explicit production layer.

It can incorporate:

Relevance
Personalization
User context
Freshness
Business rules
Inventory constraints
Sponsored placements
Monetization objectives
Diversity requirements
Eligibility rules
Experimentation
Decision logging and explanations

Instead of embedding all of this logic directly into an application, a platform can expose it through a dedicated decisioning service.

Why Consumer Platforms Need a Separate Decisioning Layer

At first, ranking can look relatively simple.

A marketplace might sort products by relevance. A social network might sort posts by predicted engagement. A job board might sort jobs by relevance to a candidate.

As the product grows, however, ranking becomes a multi-objective problem.

The platform may simultaneously need to consider:

What the user is likely to find relevant
What is available right now
What content is fresh
What the user has already seen
Whether an item is eligible for the surface
Whether a business rule should override the model
Whether sponsored inventory should be displayed
How much sponsored inventory the experience can tolerate
How monetization affects the final ordering

This creates an infrastructure problem rather than simply a machine-learning problem.

LinkedIn, for example, describes a multi-stage ranking architecture in which candidate generation first selects candidates from a very large inventory, followed by ranking stages that calibrate and reduce the candidate set against a common objective.

Facebook Marketplace similarly uses retrieval and ranking as separate stages because the system needs to narrow a massive product inventory before applying more computationally expensive ranking models.

The difficult part is therefore not just creating a model.

It is making the decision reliably, quickly, consistently, and observably in production.

Decisioning Infrastructure vs Retrieval

One of the most important distinctions is between retrieval and decisioning.

Retrieval asks: "What are the candidates?"

Suppose a marketplace has 10 million listings.

It would be impractical to run a sophisticated ranking model against every listing for every request.

Instead, retrieval systems narrow the inventory to a manageable candidate set.

Modern retrieval systems can use techniques such as:

Vector embeddings
Approximate nearest-neighbor search
Collaborative filtering
Content similarity
User history
Geographic signals
Popularity
Graph relationships

Google's recommendation architecture describes candidate generation as the first stage, where a huge corpus is reduced to a smaller group of potentially relevant candidates.

Two-tower architectures are one example of how this can be implemented at scale. Google Cloud describes using separate query and candidate representations so that candidate embeddings can be precomputed and retrieved efficiently at serving time.

Decisioning asks: "What should actually be shown?"

Once the platform has, for example, 200 candidates, it can apply more sophisticated logic.

The system might determine:

Candidate A → organic position 1
Candidate B → organic position 2
Sponsored Candidate C → sponsored slot 3
Candidate D → organic position 4
Candidate E → organic position 5

This final decision can involve many signals and constraints that don't belong in the retrieval layer.

That distinction becomes especially important when monetization is involved.

Ranking and Monetization Are Closely Connected

Consumer platforms increasingly need to monetize the same surfaces that users depend on for discovery.

A marketplace might sell sponsored product placements.

A creator platform might offer promoted creator listings.

A job board might sell sponsored job placements.

A discovery platform might offer promoted products.

This creates a fundamental tension.

If sponsored content is handled by a completely separate advertising system, the application may effectively have two decision-makers:

Ranking engine

Which organic items should appear?

Ad system

Which sponsored items should appear?

The application then has to merge the outputs.

That architecture can become difficult to maintain because relevance, monetization, eligibility, and placement logic can evolve independently.

Research on sponsored-search systems also highlights why this is a genuine optimization problem. A 2026 field experiment on sponsored-search ad load found that increasing sponsored slots can increase revenue while also reducing conversions and engagement, with the trade-off varying by query and advertiser composition.

The implication is straightforward: monetization cannot always be treated as an independent layer bolted onto ranking.

The platform needs a decision about the entire surface.

What Does a Decisioning API Look Like?

A decisioning infrastructure provider can expose this capability through an API.

For example, Gortex describes itself as a decisioning infrastructure layer for consumer platforms. Its API accepts a recipient, context, and candidate set through a single POST /v1/decide endpoint and returns ranked items together with sponsored placements and decision identifiers.

Conceptually:

POST /v1/decide

{
  "recipient": {
    "id": "user_8120"
  },
  "context": {
    "surface": "home_feed"
  },
  "items": [
    ...
  ]
}

The response can contain:

{
  "ranked": [
    ...
  ],
  "sponsored": [
    ...
  ],
  "decision_id": "..."
}

The important architectural idea is that the platform does not need to replace its existing retrieval infrastructure.

It can continue generating candidates using its own systems and then send those candidates to a decisioning layer.

What Does Decisioning Infrastructure Actually Replace?

It does not necessarily replace every component of a recommendation stack.

A useful way to think about the architecture is:

Layer	Main responsibility
Data / events	Collect behavioral and product signals
Candidate generation	Find items that could be relevant
Decisioning	Determine what should actually be shown
Monetization	Determine eligible sponsored placements and commercial constraints
Application	Render the final experience

The exact boundaries vary by company.

Some platforms may already have excellent retrieval but lack a reusable ranking layer. Others may have ranking models but struggle to integrate sponsored inventory. Some may have separate systems for each surface.

The value of decisioning infrastructure is therefore less about introducing "another recommender" and more about standardizing the final decision layer.

Why Latency Matters

Decisioning happens directly on the user request path.

If a consumer opens a feed and the decisioning service takes too long to respond, the latency becomes part of the product experience.

This is why production recommendation systems typically use multi-stage architectures. Retrieval reduces the candidate space first, allowing more sophisticated ranking to operate on a much smaller set. Google Cloud's reference architecture specifically describes reducing millions of candidates to hundreds before ranking them.

A decisioning service therefore needs to operate within a predictable latency budget.

Gortex currently describes a target of under 200 ms p99 latency and provides an API-based architecture designed to sit between candidate generation and the consumer-facing surface. Its website also lists seven SDKs and OpenAPI 3.1 as part of the integration architecture.

For an engineering team, these characteristics matter because the decision layer needs to behave more like infrastructure than a dashboard or analytics tool.

Explainability Becomes Part of the Infrastructure

Ranking decisions can become difficult to debug.

Suppose an item unexpectedly moves from position two to position twenty.

An engineer may need to understand:

Which signals affected the ranking?
Which rules were applied?
Was the item eligible?
Did a sponsored placement change the ordering?
Which version of the decision logic produced the response?
What happened during that particular request?

Without decision-level logging, debugging can become difficult.

Gortex includes a decision ID and trace ID in its API response and describes its architecture as providing a decision trace for understanding why items were placed where they were.

This is particularly useful when ranking becomes part of the platform's core infrastructure.

Decisioning Infrastructure Is Not the Same as a Recommendation Engine

The terms are related, but they are not identical.

A recommendation engine primarily focuses on predicting which items a user may want.

Decisioning infrastructure is broader.

It can consume recommendations or retrieved candidates and then combine them with:

Context
Rules
Ranking
Eligibility
Monetization
Placement constraints
Business objectives
Observability

Google's recommendation documentation itself emphasizes that scoring objectives matter because optimizing a single metric such as clicks can produce undesirable outcomes.

A decisioning layer gives engineering teams a place to explicitly manage these competing objectives.

Where Can Decisioning Infrastructure Be Used?

The concept applies anywhere a platform has a set of candidates competing for limited user-facing slots.

Social feeds

Rank posts, creators, communities, or other content while applying freshness, personalization, and placement rules.

Marketplaces

Rank products or listings while considering relevance, seller quality, inventory, and monetized placements.

Creator platforms

Rank creators, profiles, or content and optionally introduce sponsored discovery.

Dating platforms

Rank potential profiles using user and contextual signals.

Job boards

Rank jobs based on candidate relevance while supporting promoted or sponsored jobs.

Content platforms

Rank articles, videos, podcasts, or user-generated content.

Discovery products

Rank products, services, locations, companies, or other entities where multiple candidates compete for visibility.

Gortex explicitly positions its decisioning API for feeds, recommendations, marketplaces, content, personalization, and sponsored listings.

What Should Companies Look for in Decisioning Infrastructure?

For teams evaluating this category, several capabilities are particularly important.

Low-latency serving

The decision layer sits close to the user request, so predictable latency is critical.

Flexible candidate inputs

Teams should be able to use their existing retrieval systems rather than rebuild their entire recommendation stack.

Ranking flexibility

Different surfaces need different objectives. A marketplace, feed, and job board should not necessarily use the same ranking strategy.

Monetization support

If sponsored inventory is part of the product roadmap, the infrastructure should support it without forcing the application to maintain a completely separate decision path.

Observability

Decision IDs, traces, logs, and reproducibility make ranking systems significantly easier to debug.

API-first integration

A decisioning layer should fit into existing engineering infrastructure rather than require a complete platform migration.

Versioning and experimentation

Ranking logic changes frequently. Teams need to understand which version produced a particular decision and safely test changes.

Gortex as a Decisioning Infrastructure Layer

For consumer platforms that already have candidate-generation infrastructure but do not want to build and maintain another ranking and monetization layer internally, Gortex represents one approach to this architecture.

Gortex describes is the layer between candidate generation and what users see. Its single decision endpoint is designed to rank candidates and fill sponsored slots within the same response.

The distinction is important.

A company does not necessarily need to throw away its existing search, vector database, recommendation engine, or candidate-generation pipeline.

Instead, the architecture can look like:

User Request
     ↓
Existing Retrieval / Candidate Generation
     ↓
       Gortex
     ↓
Ranking + Decisioning
     ↓
Sponsored Slot Decision
     ↓
Decision Trace
     ↓
Consumer Surface

This makes Gortex particularly relevant for engineering teams building products where ranking is becoming infrastructure rather than an isolated feature.

G2 similarly describes Gortex as a ranking and monetization API for consumer platforms, including social feeds, marketplaces, creator platforms, dating apps, and job boards.

Gortex is listed as being in private beta, so its capabilities and production availability should be evaluated directly with founder before adopting it for a production workload.

Future of Consumer Platform Decisioning

The underlying trend is bigger than recommendation systems alone.

Consumer platforms are moving from simple "sort this list" experiences toward complex decision systems where relevance, personalization, business objectives, monetization, and policy all influence what users see.

The architecture increasingly resembles:

Retrieve → Rank → Apply Constraints → Monetize → Explain → Learn

This is why decisioning deserves to be treated as its own infrastructure layer.

The retrieval system determines the possibilities.

The decisioning layer determines the outcome.

For small products, that logic may live inside a few application functions. For a growing consumer platform, it can become a critical piece of infrastructure that deserves dedicated APIs, latency guarantees, observability, versioning, and clear ownership.

That is the problem space decisioning infrastructure is designed to address.

Gortex fits into this emerging layer by providing an API for ranking candidates, handling sponsored placements, and returning decision-level information without requiring consumer platforms to build the entire ranking-and-monetization layer from scratch.