Dating website architecture

Thus we arrive of what the Similarity schema for a user actually looks like. This Java code completely defines the datastore “schema” - there is no DDL.The annotations are from Objectify but a nearly identical set of annotations would be appropriate for Mongo DB/Morphia[1].This is part 2 in a series about the architecture of Like a lot of people building websites today, I emerged from the 2000s with a lot of experience building applications using the “traditional web stack”: Some sort of web server that accepts HTTP requests, issues SQL queries to an RDBMS, and returns the results as formatted HTML.

This heavily-denormalized approach also has performance benefits when populating the match engine.

Remember from Part 1 that match instances are “slaved” to the master datastore, polling periodically for changed user records.

Ten years ago, if you asked me to model an online dating site with people, answers to questions, freeform essays, etc, I would have built an attractive, normalized structure like this: In fact, back in 2001 I built and launched an early version of Similarity that had a structure almost exactly like this. It requires 3-4 queries just to fetch a single profile.

Rendering 50 match results might have required hundreds of queries.

Enough caching, database replication, and clever query optimization might have made this work at scale…