DEV Community

Cover image for Designing the Backend Architecture for a Multi-Category Services Platform
Anurag Seervi
Anurag Seervi

Posted on

Designing the Backend Architecture for a Multi-Category Services Platform

Building a platform like ServiceTasker — a multi-category services marketplace — is not just about getting listings online. The real complexity lies under the hood: designing a backend architecture that is flexible, scalable, and optimized for real-time interactions across different services like plumbing, pest control, electricians, and more.

In this article, we’ll walk through the backend architectural decisions behind building such a platform, the database models, API layers, and how we handled category flexibility, provider-customer interaction, reviews, and booking flows.

Whether you're building a similar services marketplace or a niche gig-based platform, this guide will help you understand the foundational backend considerations.

1. Project Setup and Stack

Tech Stack Chosen:

  • Backend: Node.js with Express (could be Laravel or Django too)
  • Database: PostgreSQL (relational structure helps for multi-relational data)
  • Caching: Redis (for sessions and frequently accessed data)
  • Authentication: JWT with role-based access
  • Storage: AWS S3 (for storing profile photos, invoices, etc.)
  • Queue Management: Bull (for job queues like email reminders)

We used ServiceTasker (by SAER Technologies) as the real-world build, which handles hundreds of subcategories across multiple cities in Australia.

2. Designing the Core Database Schema

To support multiple service categories, providers, cities, and customer actions, we designed a modular and relational DB structure.

Key Tables:

  • users (with roles: customer, provider, admin)
  • categories → (e.g., Electricians)
  • subcategories → (e.g., Emergency Electricians)
  • locations → (e.g., Sydney, Melbourne)
  • services (actual listings posted by providers)
  • bookings
  • reviews
  • quotes (optional quoting system)
  • notifications

Example: Services Table Schema

This allows us to easily filter or group services by location, category, or both — perfect for URLs like:

3. API Layer with REST + Role-Based Logic
We designed a modular REST API layer with Express, structured as:

  • /api/auth/ → login, signup, role assignment
  • /api/services/ → list, create, update
  • /api/bookings/ → book service, cancel, reschedule
  • /api/users/ → view profiles
  • /api/reviews/ → submit/view reviews
  • /api/quotes/ → (optional) handle quote requests Each route checks the JWT and enforces role-based access:


4. Handling Category and Subcategory Logic

Each category and subcategory can have unique attributes. To avoid schema bloat, we used a JSONB column in PostgreSQL to store additional dynamic fields.

For example:

This keeps the core schema clean while supporting attribute variations across service types.

5. Booking System Architecture

The booking flow was the most complex part:

  • The user selects a service
  • Choose a time slot (if enabled)
  • Enter the address and confirm the booking
  • Provider gets notified
  • Status transitions: pending → accepted → completed → reviewed We stored each transition with timestamps for analytics and audit:

6. Notifications and Real-Time Updates

For notifications, we used:

  • Redis + Bull for email reminders and job queues
  • WebSockets (Socket.io) for real-time chat between users and providers
  • Push notifications via Firebase (for mobile version)

7. Search & Filters

To handle filtering by:

  • Location
  • Category/Subcategory
  • Rating
  • Price ...we created index-based queries and used ElasticSearch for advanced search in later iterations.

We implemented geolocation support via PostGIS to enable “near me” functionality.

8. Review System with Fraud Detection

To reduce fake reviews, we:

  • Allowed reviews only after completed bookings
  • Used IP logging and email flags to spot duplicate accounts
  • Built a backend script to flag suspicious review patterns

This helped ensure genuine trust signals across the ServiceTasker platform.

9. Admin Dashboard

Admins needed to:

  • Approve new service providers
  • Suspend fake profiles
  • Edit listings
  • Moderate reviews We built a separate admin dashboard with role-level restrictions and bulk update tools using DataTables + Bootstrap.

10. Scalability Considerations

Some optimizations included:

  • Load balancing using Nginx
  • Horizontal scaling for the app server (Node.js cluster mode)
  • Read replicas for the database in high-traffic areas
  • Daily cron jobs to clean inactive data

11. Testing and DevOps

  • Just for unit and integration tests
  • Postman + Swagger for API documentation
  • Docker for isolated environments
  • CI/CD using GitHub Actions

Final Thoughts

Designing the backend architecture for a multi-category services platform like ServiceTasker isn't trivial. It requires thoughtful modeling, extensible schemas, and strong API controls. By modularizing components like bookings, reviews, and notifications, we created a system that's flexible enough to support everything from local electricians in Sydney to tree removal pros in Adelaide.

Whether you’re planning to build a similar platform or contributing to one, I hope this walkthrough gives you real-world insight into making scalable service systems work.

Top comments (0)