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.

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:

  • The backend holds the shared data and enforces its server-side rules, including pricing, availability, booking permissions, and booking state changes. It is the authority for those enforced rules.
  • 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 clients of the backend. They do not talk directly to each other. The backend handles shared data and server-side rules. A client can also have its own navigation, display, or local-state behavior. When sources differ, these docs state the backend rule and the client behavior separately.

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 bus group. 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 cannot do. A coordinator is not staff and has no staff-level access.

How to read this documentation set

This repo has one documentation track:

  • This business-logic set describes what the system is supposed to do, in plain language, for anyone, engineer, designer, or product owner, who needs the rules without reading code. These pages are the single source of truth for Aashray business logic.

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.