Full Stack Web-Developer

Overview: Architecture Gap Analysis (Current Monolith vs. Target Microservices) The current codebase operates as a single Next.js modular monolith deployed on a single domain. While functionally rich, it lacks physical service boundaries, independent deployability, distributed infrastructure, and dedicated subdomains specified in the target architecture. --- 1. Frontend & Domain Separation * Unified Domain & Path Routing: Everything runs under the primary domain (www). Portals are split by URL paths (/admin, /vendor, /partner, /agent/visa) rather than distinct subdomains (admin., vendor.). * Single Deployment Artifact: Public, user, admin, and vendor frontends build and deploy as a single Next.js application. * No Subdomain Traffic Splitting: DNS and next.config.mjs do not route or isolate traffic by portal. * Responsive Web Only: No dedicated mobile app frontend or native API layer, despite future mobile support requirements. --- 2. Backend & API Layer * Colocated API Endpoints: User APIs (/api/*) and admin/vendor logic live on the main domain rather than standalone hosts (api. or backend.). * Implicit Gateway Layer: Lacks a dedicated API Gateway. Traffic relies strictly on Vercel Edge rules and src/proxy.ts middleware. * Monolithic API Execution: Approximately 180 route handlers run inside a single Next.js process instead of isolated domain APIs (Auth, Booking, Payment, Search, Wallet, Notifications). * Missing Infrastructure Standards: * No Service-to-Service Auth: Zero internal token exchange or inter-service security patterns. * No API Versioning: Endpoints lack formal versioning prefixes (e.g., /v1/). * Tightly Coupled Scaling: API capacity cannot be scaled independently by domain or load profile. --- 3. Microservices & Modular Boundaries The following target services exist strictly as internal utility libraries or route handlers inside the monolith: * Auth Service: Embedded in nextauth.ts and shared utility modules. * User Service: Intermingled across customer and admin API routes. * Booking Service: Flights, hotels, trains, visas, and cabs share a single codebase. * Payment Service: Payment logic resides in route handlers and shared helper files. * Search Service: In-process execution within the primary Next.js runtime. * Notification Service: In-app and email dispatch logic embedded in handlers. * Wallet Service: Customer, partner, and vendor wallets share one database and app logic. * Inventory Service: Vendor inventory (hotels, cabs) is managed inside monolith routes. * Earning & Payout Service: Partner/vendor payouts executed via inline route handlers. * Document Service: File processing handled inline via s3-upload.ts. * Review Service: Reviews are directly coupled to core database schemas. * CMS Service: Admin routes coupled with cms-server.ts. * Audit Log Service: Synchronous database writes via a shared utility library. * Reports / Analytics Service: Direct in-process query execution during admin requests. --- 4. Database Layer * Single Instance & Shared Schema: One shared PostgreSQL database (DATABASE_URL) without read/write splitting or a read replica setup. * No Database-per-Service: Complete schema shared across all domains, preventing logical and physical isolation. * Unmanaged Migration History: Uses db push and manual SQL scripts instead of versioned prisma migrate history. * Runtime Schema Creation: Tables created dynamically on application boot (ensure*Schema), posing operational risks in production. * Disaster Recovery: No documented automated backups, point-in-time recovery, or failover plans in source control. --- 5. Shared Infrastructure & Async Processing * Missing Distributed Cache: @upstash/redis is listed in package.json but unintegrated; no shared caching layer exists. * No Message Broker / Task Queue: Lacks asynchronous queues (BullMQ, RabbitMQ, Kafka, or SQS). Background operations rely on cron endpoints. * Synchronous Workflows: Emails, reports, refunds, and notifications run synchronously inside HTTP requests. * Mocked Integrations: * SMS: Cab notifications write directly to server logs (cab-workflow-notifications.ts). * Push Notifications: Lacks FCM, APNs, or Web Push integrations. * Edge & Network Limitations: * Lacks explicit CDN configurations for static assets beyond basic provider defaults. * Lacks a dedicated Load Balancer / Gateway tier. * File storage (S3/R2) operates via local utilities rather than a managed storage microservice. --- 6. Observability, Security & Monitoring * Observability Void: No integration for Prometheus, Grafana, ELK, or distributed APM tracing (e.g., OpenTelemetry, Datadog). * Missing Error Tracking: Sentry is referenced in codebase comments but not wired into application runtime. * Unstructured Logging: Logging depends on standard console.log / console.error without centralized log shippers. * Edge Security: No Web Application Firewall (WAF) configuration or dedicated DDoS mitigation policies. * Stateful Rate Limiting: src/lib/rate-limit.ts uses local in-memory state, failing across multi-instance or serverless deployments. * Network Isolation: Zero network segmentation between internal services or backend endpoints. --- 7. Scalability & Deployment Mechanics * Monolithic Build Pipeline: Single package.json build process; updating one line requires redeploying the entire system. * Real-time Server Coupling: Socket.IO requires a persistent server (server.ts), conflicting with serverless deployment models and microservice patterns. * No Orchestration Layer: Lacks Docker Compose, Kubernetes, or container orchestration manifests. * Single-Region Risk: No redundancy or multi-region failover strategy configured. --- Summary Architectural Divergence Target Architecture: Subdomain Frontends - Current Codebase: Single Next.js Monolith Target Architecture: API Gateway - Current Codebase: Middleware Proxy (src/proxy.ts) Target Architecture: Isolated Microservices - Current Codebase: ~180 Route Handlers Target Architecture: Database-per-Service - Current Codebase: Single Shared PostgreSQL DB Target Architecture: Async Event Broker/Queue - Current Codebase: Synchronous Cron Endpoints Bottom Line: The target architecture specifies a distributed, highly scalable microservices platform with clear domain isolation, dedicated subdomains, asynchronous event processing, and isolated infrastructure. The current codebase is a feature-rich modular monolith. While it works as a unified application, transitioning to the target state requires extracting domain services, decoupling the database, implementing an event broker, and configuring dedicated infrastructure.