Full-Stack Developer for Tennis Booking Platform

coaches, 200 registered members, and roughly40 daily orders. ●High Availability Target: Optimized high-concurrency server responses during keyoperating hours (5:00 PM to 11:00 PM daily).2.Core Infrastructure & Deployment Architecture To completely isolate operational and industry liabilities, this system will NOT use a standard SaaS multi-tenant architecture. ●Absolute Isolation (1:1 Single-Tenant Cloning Model): The codebase and databaseinfrastructure must be designed for seamless containerized replication. Each subsequentmerchant/venue instance will be deployed on a completely isolated server environmentwith an independent domain, independent database, and private server resources. ●Hosting Environment: Overseas cloud infrastructure based in Singapore (e.g., AWS,DigitalOcean, or Alibaba Cloud International). ●Recommended Stack: ○Backend: Node.js (NestJS) or Python (FastAPI / Django) for fast deployment andAPI speed. ○Frontend: Responsive H5 Web Application (Vue.js or React) optimized perfectlyfor both mobile (safari/chrome/wechat/alipay browsers) and desktop, removing theneed for a native app.3.Core Functional Modules & Technical Requirements 3.1 Advanced Booking Grid Engine ●Fixed Time-Slot Bundling: Bookings will be grouped into pre-configured bundles (e.g.,7–9 PM, 9–11 PM, 11 PM–1 AM, 1 AM–4 AM, 7 PM–12 AM, 12 AM–4 AM). ●Overlapping Collision Matrix: The system must actively map clashing timeframes. Forexample, if a user successfully locks the long slot (7 PM–12 AM), the backend databasetransaction must automatically lock out smaller, overlapping sub-slots (7–9 PM and 9–11PM) for that specific court. ●The 10-Minute Hold & 5% Deposit: Checking out a slot triggers a 10-minute databasehold lock. Users must pay a 5% non-refundable deposit via global payment rails toofficially secure the booking. This deposit is fully deducted from the final on-site tab. 3.2 Stored-Value Tiered Rolling Wallet (Core Algorithmic Challenge) Users can top up their virtual wallet with any customized decimal amount in RMB (1 RMB = 1 Base Credit). ●Rolling 365-Day Window ($C_[12m]$): Bonuses are dynamically calculated based onthe user's absolute aggregate top-ups over the preceding 365 days (tracked precisely tothe second). ●Tiered Multipliers: ○Tier 0 ($C_[12m] below 5,000\text[ RMB]$): 1.0x (No bonus). ○Tier 1 ($5,000 \le C_[12m] below 30,000\text[ RMB]$): 1.1x (+10% promotional bonuscredits). ○Tier 2 ($C_[12m] \ge 30,000\text[[ RMB]$): 1.2x (+20% promotional bonus creditsfor amounts exceeding 30,000). ●Cross-Tier Fragmentation: If a single large top-up crosses multiple tiers, the backendmust split the cash volume into segmented buckets to process multipliers accurately. Forexample, if a user has a historical 365-day total of 4,000 RMB and deposits 30,000 RMB,it must be split into: 1,000 RMB at 1.0x, 25,000 RMB at 1.1x, and 4,000 RMB at 1.2x. ●Audit-Compliant Ledger: Every single wallet update must double-write separate lineentries into a strict credits_ledger table (base_credits_delta and bonus_credits_delta) forcomplete financial visibility. 3.3 Peer-to-Peer (P2P) Coach Tipping Ecosystem ●Direct Wallet Transfer: Clients can tip coaches directly inside their H5 profile. To ensurefriction-free execution, tipping bypasses standard payment gateways and directly debitsthe client's internal virtual wallet point balance and credits the coach's ledger. ●Tipping skips the main court invoice bill and is completely unaffected by storecoupons/discount codes. Coaches can view their accumulated tips in an internal pointsdashboard, which administrators will process and pay out manually offline once a week. 3.4 Cross-Border Payment Gateway Integration ● Primary Gateway: Stripe integration to natively capture WeChat Pay and Alipay mobile wallet transactions globally. ● Backup Gateway: PayDollar setup as an uncoupled architecture layout, ready to be manually toggled by admins via the backend if Stripe encounters compliance audits or downtime. ● No Online Refunds in Phase 1: All refunds, order disputes, or cash cashouts are entirely handled offline by the venue staff. No complex refund callback APIs are required for thisiteration.4. Technical Constraints & Security Guidelines ●Race Condition Mitigation: To prevent duplicate wallet injections or double-bookingsduring heavy traffic spikes, developers must implement strict Row-Level Locking (FORUPDATE) or a Redis Distributed Lock framework within the database lifecycle. ●Data Minimization & Compliance: No local Chinese real-name validation (KYC)mechanisms are to be implemented on-server. Data collection should remain minimal,keeping tracking configurations lean.