Belza

Belza starts as a discovery layer. Users can explore nearby businesses through a marketplace designed around location, category and availability. The experience includes map-based browsing, filters and saved favorites to make finding the right business faster and more intuitive.

Each business has its own dedicated page where users can explore services, view staff, understand pricing, check location details and decide who to book with. This turns the booking flow into a more transparent and informed decision before reservation begins.

Once inside the booking flow, users can select a service, choose staff, confirm a time slot and complete the reservation in just a few steps. After booking, appointments can be managed directly through the platform — including rescheduling, cancellation and direct contact with the business.

The operational core of Belza revolves around a centralized calendar where the business manages bookings, receives online appointments, creates manual reservations, schedules staff time off and records in-store sales. This acts as the primary operational surface where day-to-day activity is coordinated.

Belza includes the commercial layer of the business, allowing teams to manage services, physical products, gift cards and promotional coupons in one place. Businesses can also control their public booking presence, enable online reservations and configure Stripe to support digital payments and booking deposits.

Belza centralizes the people layer of the business through dedicated client and staff management systems. Businesses can manage client records, track history and create new customer profiles, while also controlling staff setup, schedules, visibility and performance across the platform.

Belza extends beyond operations with tools built for retention, visibility and long-term business control. This includes a configurable loyalty system, business analytics, real-time notifications, global search and operational settings for cancellation, rescheduling and policy management.

System Design

Belza was split across independent system surfaces: a client-facing web platform, a business-facing application, internal background workers and dedicated infrastructure services. This allowed the product to behave as a unified platform while keeping operational responsibilities separated across the system.

Modular Monolith

Internally, the backend was designed as a modular monolith organized by domain. Each feature was built as its own module and structured using a hexagonal architecture to isolate business logic from infrastructure concerns. Every module was divided into domain, application and infrastructure layers, allowing core logic to remain independent from transport, persistence and external services.

Multi-Tenant Architecture

Belza’s tenancy model was designed around organizations and branches. Each organization acts as a top-level tenant, with support for multiple branch-level operational surfaces underneath. This allowed the platform to support isolated business data, branch-level workflows and multi-location growth without fragmenting the core system.

Real-Time Infrastructure

Real-time behavior was handled through server-sent events, primarily across notifications and calendar state. These systems required live operational updates without the overhead of persistent bidirectional sockets. SSE provided a simpler and more reliable model for pushing booking activity, notification events and live operational state back to the interface in real time.

Operational Reliability

To keep the system stable under operational load, asynchronous workflows were separated from the request cycle and processed through dedicated workers. Notifications, reminders, email delivery and availability workloads were handled asynchronously to reduce request pressure and improve resilience. Availability also relied on precomputed state to reduce latency in booking-critical flows, while idempotency controls protected background jobs from duplicate execution.

Core Architectural Decision

The most important architectural decision in Belza was treating the system as modular from the start. Adopting a hexagonal architecture made it possible to keep the platform decoupled, evolve features independently and reduce long-term dependence on implementation-specific infrastructure.

Booking Engine

The booking engine acts as the core decision layer behind every reservation and is the most operationally complex system in Belza. Slot generation is computed dynamically based on service duration, staff eligibility, schedule windows, booking overlaps, operational buffers and slot-level conflicts.

Every booking request evaluates whether a service can be performed by a valid staff member, whether that staff member is available within the requested time window and whether the slot remains valid once duration, overlaps and business rules are applied. Time is normalized into 15-minute intervals to keep scheduling behavior predictable, while slot holds and temporary locks protect availability during booking and payment flows.

Availability Engine

Availability is one of the most computationally expensive systems in Belza, and recalculating it on every booking request would make scheduling too slow under load. To avoid this, availability was designed around precomputed state.

Rather than rebuilding slot availability on every request, Belza computes and caches availability windows in advance using Redis. Whenever an event affects scheduling state — such as a booking change, time-off update or staff availability change — that event is pushed into a BullMQ queue where availability is recomputed asynchronously by dedicated workers.

This allows booking-critical reads to resolve from precomputed cached windows instead of rebuilding availability state in real time, significantly reducing latency in scheduling flows.

Notification System

Belza’s notification system was designed as an event-driven pipeline built around asynchronous delivery and real-time fanout.

When a relevant event occurs — such as a booking being created, cancelled or rescheduled — the application emits a notification event into a queue. A worker consumes that event, builds the notification payload, persists it to PostgreSQL and publishes a real-time update through the notification stream.

The frontend remains subscribed through server-sent events, allowing notifications to appear in real time without polling while keeping delivery decoupled from the request cycle.

Payments & Booking State

Belza’s booking and payment flows were designed to keep operational state consistent across reservation and payment lifecycles.

Bookings and payments are stored as separate but connected state systems. A booking can move through multiple operational states — including reserved, pending payment, paid, completed, cancelled or rescheduled — while payment state is tracked independently and reconciled back into the booking.

This separation allows Belza to support payment holds, Stripe checkout flows, partial payments and delayed state transitions without collapsing booking and payment logic into the same lifecycle model.