Hosting & Infrastructure
Hububb uses a hybrid stack on Google Cloud Platform (GCP) and Firebase to balance security, scalability, and developer velocity. At a glance:
Frontend: Next.js (Web & Dashboard) on Firebase App Hosting / Hosting
Backend API: NestJS on Cloud Run (Docker)
Databases: Cloud SQL (PostgreSQL) for transactional data + Firestore (NoSQL) for real-time chat
Identity: Firebase Authentication (Email+Password, Google, Apple)
Storage: Firebase Storage for media
Orchestration: Cloud Tasks (retries/queues), Cloud Scheduler (cron)
Secrets: GCP Secret Manager
CI/CD: GitHub → automatic deploys per environment (Dev/Prod)
High-Level Architecture
All data changes must pass through Hububb’s API/dashboards to maintain invariant and auditability. Real-time channel/state sync is performed via the API rather than direct edits in third-party systems.
Components (What, Why, Security, Scale)
Frontend (Next.js 15) on Firebase App Hosting / Hosting
What it does:
Serves the landlord dashboard and web app with global edge caching and automatic SSL.
Why we chose it:
Low-latency global CDN, atomic rollouts/rollbacks, preview channels for PRs, consistently strong TLS defaults.
Security:
End-to-end HTTPS (TLS) by default
Immutable builds with atomic deploys; easy rollback if needed
Optional headers (HSTS, CSP, X-Frame-Options) controllable at hosting config level
Access tokens never embedded; read-only public configs via Firebase environment config
Scale/Resilience:
Edge-cached static assets + serverless SSR/ISR patterns supported
Instant rollbacks and preview channels for safe iteration
Backend API (NestJS) on Cloud Run (Docker)
What it does:
Hosts all business logic, channel integrations, webhooks, calendars, pricing updates.
Why we chose it:
Per-request isolation, secure defaults, horizontal auto-scaling, rollbacks via revisions, and container portability.
Security:
gVisor sandboxing and per-request container isolation on Cloud Run
IAM per service (only required identities can invoke the service)
Private connectivity to Cloud SQL (no public DB exposure)
Secrets pulled only from Secret Manager (no plaintext env vars in repo)
Strict CORS and auth middleware at the API layer (JWT/ID token validation)
Scale/Resilience:
Auto-scale to zero and up based on concurrency
Multiple revisions for safe rollouts; gradual traffic splitting supported
Cloud SQL (PostgreSQL)
What it stores:
Core transactional data: properties, rooms, rate plans, reservations, purchases, services, etc.
Why we chose it:
Relational integrity, mature SQL tooling, and strong operational posture on GCP.
Security:
Encryption at rest and in transit (TLS)
Private IP connectivity from Cloud Run (no public endpoint)
IAM-governed access and connection controls
Automated backups & Point-in-Time Recovery (PITR) available
DB credentials read from Secret Manager only
Scale/Resilience:
Vertical/Horizontal scaling (read replicas), automated maintenance windows
High-availability configurations (regional)
Firestore (NoSQL) — Real-time Chat & High-frequency State
What it stores:
Chat threads/messages and real-time UX state where flexible schema and live updates are needed.
Why we chose it:
Sub-second real-time sync, offline support, cost efficiency for chat-style workloads.
Security:
Firestore Security Rules (auth-aware, document-level)
Server-side checks in API for critical paths
Encryption at rest/in transit; IAM for server SDK access
Scale/Resilience:
Horizontal scaling with global distribution
Real-time listeners push updates without polling
Firebase Authentication
What it does:
Single identity platform across web and API.
Providers:
Email/Password, Google, Apple.
Security:
Token-based auth (ID tokens) verified server-side
Built-in email verification, password policies, and account protection
No custom credential storage in code — reduces attack surface
Scale/Resilience:
Fully managed, battle-tested auth flows; seamless provider upgrades
Firebase Storage (Media)
What it stores:
Property photos, videos, and other landlord assets.
Security:
Access via Storage Security Rules + signed URLs where needed
Encryption at rest/in transit
Objects versioned and served via Google’s secure infra
Scale/Resilience:
Global object store with CDN-friendly delivery
Cloud Tasks (Asynchronous Jobs)
What it does:
Reliable background execution with automatic retries, exponential backoff, and dead-letter routing.
Use cases:
Email sending, reservation syncs, OTA pulls/pushes, heavy updates that shouldn’t block API responses.
Security:
Each queue invokes targets using a service account identity (IAM)
Per-queue rate limits and max concurrent dispatch to prevent abuse
Scale/Resilience:
Region-scoped queues, durable persistence, retry semantics to ride out transient failures
Cloud Scheduler (Cron)
What it does:
Triggers scheduled jobs (e.g., nightly sync, cleanup, health checks).
Security:
Invokes HTTP targets with OIDC-signed requests on a service account
Fine-grained IAM: only permitted schedulers can call specific endpoints
Scale/Resilience:
Managed, highly available cron — no VM to maintain
Secret Manager
What it stores:
DB credentials, third-party API keys, sensitive configs.
Security:
IAM-gated access; only runtime identities that need a secret can read it
Versioned secrets with audit logging and easy rotation
Supports CMEK (customer-managed encryption keys) if required
Best practice we follow:
No plaintext secrets in code or CI logs. The API loads secrets at runtime directly from Secret Manager.
CI/CD & Environments
Environments:
Development and Production, each with isolated Firebase projects, Cloud Run services, databases, and secrets.
CI/CD flow:
GitHub → automatic deploys on push
Backend: build Docker image, deploy to Cloud Run, bind to the correct Secret Manager versions and Cloud SQL instance
Frontend: build and deploy to Firebase Hosting (per-env configs via Firebase YAML)
Preview channels for frontend changes; revisions/traffic splitting for backend
Benefits:
Reproducible builds, minimal drift
Fast rollbacks and safe canaries
No manual credential handling (everything is IAM + secrets)
End-to-End Security Posture
Transport security: HTTPS everywhere (TLS), signed OIDC calls for scheduled jobs
Data security: Encryption at rest/in transit across Cloud SQL, Firestore, Storage
Identity & access: Principle of least privilege via IAM for services, queues, schedulers, and secrets
Network: Private connectivity between Cloud Run and Cloud SQL; no public DB endpoints
Config & Secrets: Secrets only in Secret Manager; environment-specific configs in Firebase/GCP
Auditability: GCP audit logs for access to secrets and infra changes
Reliability: Automated backups, PITR (SQL), Cloud Tasks retries, and managed schedulers
Why This Stack Works for Hububb
Secure by default: Managed services (Cloud Run, Cloud SQL, Firebase) reduce attack surface.
Scales with usage: Serverless components auto-scale without ops toil.
Lower operational risk: No VM patching, no self-managed reverse proxies/CDN.
Fast iteration: Preview deploys for the web, revisions for the API, and CI/CD on every push.
Single source of truth: All OTA/channel changes flow through Hububb to keep state consistent and avoid double bookings.
Notes on Operations
All property/channel edits must be done inside Hububb (not directly in third-party tools). We maintain mapping sync and prevent drift.
Direct DB access is locked down; all writes go through the API so we preserve invariants and auditability.
If a secret rotates, the runtime picks up the new Secret Manager version without code changes.