Apps like RealHive match two groups of people: property seekers with owners, tenants with landlords. MongoDB works well for this, as long as the schema is shaped around how the app reads data rather than how a relational diagram would look.

Design for your queries

List the screens first. For a property marketplace:

  • A search screen filtering listings by location, price and type
  • A listing page with photos, details and the owner's public profile
  • A conversation between a seeker and an owner

Each screen should need as few queries as possible.

Embed what you always read together

A listing's photos, amenities and address are only ever shown with the listing, so they live inside it:

{
  title: '2-bedroom apartment, Kilimani',
  price: 65000,
  location: { type: 'Point', coordinates: [36.78, -1.29] },
  photos: [{ url: '…', caption: 'Living room' }],
  amenities: ['parking', 'backup water'],
  owner: ObjectId('…'),
}

Reference what's shared or grows without limit

The owner is shared across many listings, so listings store the owner's id. Messages grow without limit, so they live in their own collection with a conversation id, never as an ever-growing array inside a document.

Index for the search screen

Searches filter on several fields at once. A compound index that matches the common filter order, plus a geospatial index for "near me" searches, keeps them fast:

listingSchema.index({ type: 1, price: 1 })
listingSchema.index({ location: '2dsphere' })

Copy small, stable fields

It's fine to store the owner's display name on a listing so the search results don't need a second query. Just accept that you'll update those copies when the name changes, which is rare.

The guiding question is always the same: what does this screen need, and how do I get it in one read?