Bhalobasha: Designing a Bangladesh Rental Platform

I built Bhalobasha as a Bangladesh-focused rental platform and as a practical way to explore backend architecture, relational data modeling, authentication, authorization, and system design.

The backend uses NestJS, Prisma, and PostgreSQL.

The project started from a relatively simple idea: people need a structured way to discover rental properties, while property owners need a way to publish and manage their listings.

But once the basic idea is translated into software, the domain becomes much more interesting.

Starting with the domain

Before thinking about infrastructure, I wanted to understand the actors and workflows in the system.

The application has three primary roles:

SEEKER
  |
  +-- Browse listings
  +-- Search properties
  +-- Favorite listings
  └-- Interact with rental opportunities

OWNER
  |
  +-- Create listings
  +-- Manage listings
  +-- Receive interactions
  └-- Manage property information

ADMIN
  |
  +-- Platform-level operations
  +-- Moderation
  └-- Administrative management

This immediately creates an authorization problem.

A user being authenticated does not mean that the user can perform every operation in the system.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

That distinction becomes important throughout the backend.

Why PostgreSQL?

The rental domain contains relationships between many entities.

For example:

User
 |
 +---- Listings
 |
 +---- Favorites
 |
 └---- Bids / rental interactions

Listing
 |
 +---- Owner
 |
 +---- Location
 |
 +---- Favorites
 └---- Bids

This type of relational structure fits naturally into PostgreSQL.

The database is not simply storing independent documents. It needs to represent relationships and maintain consistency between related records.

That was one of the reasons PostgreSQL was a natural fit for this project.

Prisma as the data-access layer

I used Prisma to work with PostgreSQL from the TypeScript backend.

One benefit is having a strongly typed interface between the application and the database.

The workflow becomes roughly:

HTTP request
     |
     v
NestJS controller
     |
     v
Service / business logic
     |
     v
Prisma
     |
     v
PostgreSQL

This separation keeps HTTP concerns away from database operations and makes the application easier to reason about.

Listings are the center of the domain

The listing is one of the core entities in the application.

A listing needs information such as:

• Property information
• Owner
• Location
• Availability
• Rental details
• Listing state

But the listing does not exist in isolation.

It interacts with users, favorites, bids, and geographic information.

This is where database modeling becomes important. The goal is not simply to create tables that represent nouns. The model should support the actual workflows of the application.

Location is a separate concern

A Bangladesh rental platform needs location data.

Instead of putting a large geographic dataset directly inside Bhalobasha, I created @olism/bd-geo as a reusable package.

This gives the project a cleaner separation:

Bhalobasha
│
├── Rental domain
├── Authentication
├── Authorization
├── Listings
├── Favorites
├── Bids
└── Geographic integration
          │
          └── @olism/bd-geo

The rental application consumes geographic information without becoming responsible for maintaining the entire dataset itself.

Authentication and RBAC

The application also provides a practical place to think about authentication and role-based authorization.

A common mistake in application development is to rely too heavily on the frontend to control access.

For example, hiding an OWNER-only button from a SEEKER does not make the endpoint secure.

The backend still needs to verify the user's identity and permissions.

The intended flow is closer to:

Request
  |
  v
Authentication
  |
  v
Identify user
  |
  v
Check role / permission
  |
  v
Business logic
  |
  v
Database

The UI can improve the user experience, but the API remains responsible for enforcing access control.

Search and filtering

A rental platform also introduces a different type of backend problem: users need to find relevant listings efficiently.

Search and filtering can involve several properties at once, including location and listing attributes.

This is where database indexes and query design become important.

Rather than immediately introducing a separate search engine, I prefer to start with the database and understand the actual access patterns first.

If the requirements eventually exceed what the primary database can efficiently handle, a specialized search system can be introduced based on real requirements.

Bids and favorites

Features such as favorites and bids may look like simple CRUD operations, but they introduce relationships and state transitions.

For example, a favorite is not simply another field on a user. It represents a relationship between a user and a listing.

Similarly, a bid or rental interaction has its own lifecycle and needs to be associated with the correct user and listing.

Thinking in terms of relationships and state makes the database design more useful than simply creating endpoints one by one.

Thinking about scalability

Bhalobasha is also part of my system-design learning.

I am deliberately not starting with a complicated distributed architecture just because the project could theoretically become large.

The first goal is a clear domain model:

Client
  |
  v
API
  |
  +---- Authentication / Authorization
  |
  +---- Listing domain
  |
  +---- Search / filtering
  |
  +---- Favorites
  |
  +---- Bids
  |
  └---- Location
          |
          v
     PostgreSQL

From there, individual bottlenecks can be addressed when they actually appear.

Caching, queues, read optimization, background processing, and other infrastructure should solve real problems rather than exist simply because they are common system-design components.

What this project taught me

Bhalobasha has been useful because it connects several areas of backend development in one project.

It gives me practical problems to think about instead of studying system design only as diagrams:

• How should users and roles be modeled?
• Where should authorization happen?
• Which relationships belong in the database?
• How should listing workflows be represented?
• How should geographic data be separated?
• Which queries need indexes?
• When should work become asynchronous?
• When does caching actually become useful?
• How can the system evolve without unnecessary complexity?

These questions are much more valuable to me than memorizing a collection of architecture diagrams.

Final thoughts

Bhalobasha is still an evolving project, but that is part of the point.

I am using it to practice building a backend from the domain outward: understand the workflow, model the data, define the API, enforce authorization, and then think about deployment and scalability.

The architecture should grow with the requirements.

Start with a system you can understand. Then make it more capable when the problem demands it.