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.
Top comments (0)