Skip to content

Architecture & Data Model (the connective backbone)

Part of the Aashray Business Logic. Related: every domain file — this doc is the shared foundation they all build on. For implementation detail — exact routes, database structure, and known code-level defects — see the companion Technical Reference — Architecture & Data Model.

This is the backbone that ties the whole system together: what the three systems are, how one membership record anchors everything, and who can access what. Read this first — every domain file assumes it.

The three systems, and how they relate

Aashray is really one system exposed through two different doors:

  • One system holds all the data and enforces every rule — pricing, availability, who's allowed to book what, and what happens at each step of a booking. It is the single source of truth.
  • The member app is the front door for members. It's where they book stays, meals, travel, study sessions, and festivals, and pay for them.
  • The staff panel is the front door for staff. It's where the team manages rooms, food, travel, study sessions, festivals, wifi, maintenance, and the other day-to-day operations.

The member app and the staff panel are just two different front ends for the same underlying system — they never talk to each other directly, and neither one holds or changes data on its own. Everything a member or a staff member does passes through the shared system behind both of them. When the app and the staff panel appear to disagree about how something works, the underlying system is right and whichever client disagrees is behind.

Every person and every booking is tied to one membership record

Every member — and every guest or fellow seeker a member brings along — is ultimately represented by a single membership record. Nearly everything else connects back to that record: bookings, guests, payments, feedback, service requests, and more.

One pattern is worth remembering, because it shows up in every kind of booking: a booking always records two things — who it's for, and who made it. Most of the time these are the same person (a self-booking). But when a member books a stay, a meal, a study session, or a festival spot for a guest, or on behalf of a fellow seeker they're representing (a "mumukshu" booking), the booking records both the person it's for and the member who made it. This single idea is what makes self, guest, and mumukshu booking all work the same way across every part of the system, rather than each being a separate mechanism.

Three tiers of access

The system recognizes three distinct kinds of login, and they should never be confused with one another:

  1. A member account. This is the everyday login used in the app — a phone number and password. There's no public sign-up; every account is issued ahead of time by the centre.
  2. A staff account, with different permission levels. Staff log into the staff panel with their own credentials, and — depending on what they've been granted — can see and manage different combinations of rooms, food, travel, study sessions, festivals, wifi, and other services. Not every staff member can do everything; access is scoped per person.
  3. A lightweight travel-coordinator login. Certain travelers are designated by staff to help coordinate a specific vehicle. Rather than a full staff account, they log in with a one-time code sent to their phone, and what they can do is deliberately narrow — see Travel for exactly what a coordinator can and can't do. A coordinator is not staff and has no staff-level access.

How to read this documentation set

This system's documentation comes in two matched tracks:

  • This business-logic set (what you're reading now) describes what the system is supposed to do, in plain language, for anyone — engineer, designer, or product owner — who wants to understand the rules without reading code.
  • A companion technical reference exists for every file in this set, covering the same ground from an engineering angle: exact routes, database structure, function-level behavior, admin mechanics, and known code-level defects. Each business file links to its technical companion at the top of the page — use that link when you need implementation-level detail.

Start with this file, then read Booking Lifecycle & Engine for how a booking actually happens end to end, then move into whichever domain file matches what you're investigating: Accounts, Identity & Auth, Stay, Food, Travel, Adhyayan & Utsav, Payments, Credits & Reconciliation, Services, or Notifications, Short-links & Config. Each domain file is organized around how the business actually delivers that service — the operational process staff run, the decisions they make, the mechanics that turn a request into a real outcome — with a member's request framed as the trigger that feeds into that process, not the whole story. A member-facing "how do I ask for this" section always exists, but it isn't the spine of the document.