Home /
Introduction /
Technology Stack
Chapter 0.4 — Technology Stack
1. Purpose
This chapter defines the foundational technology choices that power travoBooks as a modern, global travel accounting and unified messaging platform. Each layer is selected for enterprise-grade reliability, predictable performance under load, financial-grade data integrity, and the operational rigor required to serve OTAs, travel agencies, and AI travel agents across multiple jurisdictions.
2. Stack at a Glance
| Layer |
Technology |
Role |
Primary IDE / Tooling |
| Frontend |
React.js |
Single-page application, partner portal, admin console, agent workstation |
VS Code + TypeScript |
| Backend |
Go (Golang) |
API services, business logic, GDS/NDC integrations, ledger engine, messaging orchestrator |
GoLand |
| Database |
MySQL Cloud Enterprise |
Transactional store, financial ledger, audit trail, multi-tenant data |
MySQL Workbench / DBeaver |
| Cache & Queue |
Redis |
Session store, rate limiter, distributed locks, job queue, real-time fan-out |
RedisInsight |
This is a deliberately small, well-understood stack. Each component is mature, widely deployed at hyperscale, and carries a strong record in financial systems.
3. Architectural Topology
┌─────────────────────────────────────────────────────────────────────┐
│ Client Tier │
│ React.js SPA • Mobile Web • Partner Embedded Apps │
└─────────────────────────────────┬───────────────────────────────────┘
│ HTTPS (TLS 1.3) · REST · WebSocket
▼
┌─────────────────────────────────────────────────────────────────────┐
│ Application Tier (Go) │
│ API Gateway · Auth · Booking · Ledger · Messaging · Reporting │
└────────────┬──────────────────────────────────────────────┬─────────┘
│ │
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────┐
│ Data Tier │ │ Cache & Queue Tier │
│ MySQL Cloud Enterprise │ │ Redis │
│ (Primary + Replicas) │ │ (Cluster + Sentinel) │
└──────────────────────────┘ └──────────────────────────┘
All four layers communicate over private network segments. Inter-service traffic between Go services uses mTLS; database and Redis traffic uses TLS 1.3 with certificate-pinned clients.
4. Backend — Go (Golang)
4.1 Why Go
| Property |
Why It Matters for travoBooks |
| Lightweight concurrency (goroutines) |
A single Go process can handle thousands of simultaneous GDS, NDC, and supplier API calls without thread-pool exhaustion |
| Channels & sync primitives |
Safe orchestration of multi-supplier search, parallel ticket issuance, and webhook fan-out |
| Static binary |
Single self-contained executable; deterministic deployments; sub-second container starts |
| Compile-time type safety |
Critical for a financial system — type errors caught before production, not at runtime |
| Garbage-collected with low pause times |
Predictable p99 latency, essential for booking and ticketing SLAs |
| First-class standard library |
Production-ready HTTP, crypto, encoding, and database packages — minimal third-party risk |
| Memory efficiency |
20–100 MB per service pod; high pod density per node lowers infrastructure cost |
| Battle-tested at hyperscale |
Used by Uber, Stripe, Cloudflare, Monzo, American Express — all financial or travel-adjacent |
4.2 IDE — GoLand (JetBrains)
GoLand is the development environment standard for the backend team. It provides:
- Native Go language intelligence with whole-project refactoring
- Integrated debugger with goroutine inspection
- Built-in race detector and memory profiler integration
- Database tools, HTTP client, and Kubernetes integration
- Code review and PR workflow via JetBrains Space / GitHub
- Consistent formatting via gofmt / goimports on save
4.3 Frameworks & Libraries
| Concern |
Library |
| HTTP routing |
chi or echo |
| Configuration |
viper + environment variables |
| Database access |
database/sql + sqlx (no heavy ORM) |
| Migrations |
golang-migrate |
| Validation |
go-playground/validator |
| Logging |
zerolog (structured JSON) |
| Metrics |
prometheus/client_golang |
| Tracing |
OpenTelemetry-Go |
| Testing |
go test + testify + dockertest |
| API spec |
OpenAPI 3 (spec-first via oapi-codegen) |
4.4 Production Characteristics
- Median latency: < 20 ms for API reads
- p95 latency: < 50 ms for non-GDS routes
- Container start time: < 1 s
- Memory per service: 20–100 MB resident
- Goroutine cost: ~2 KB per concurrent operation
- Throughput: 1,000+ RPS per modest backend node
5. Frontend — React.js
5.1 Why React
| Property |
Why It Matters for travoBooks |
| Component-based architecture |
Reuse across partner portal, admin console, and embedded white-label experiences |
| Virtual DOM |
Smooth UX even when rendering large booking lists, ledger views, and reconciliation tables |
| Vast ecosystem |
Off-the-shelf solutions for forms, tables, charts, and accessibility |
| TypeScript-first |
End-to-end type safety from API contract to UI binding |
| Strong tooling |
Vite, ESLint, Prettier, Storybook, Vitest, Playwright |
| Mature i18n & RTL support |
Required for बাংলা, English, Hindi, Arabic — and right-to-left languages |
| Server-side rendering option |
Next.js available for marketing surfaces and SEO-critical pages |
| Concern |
Choice |
| Build tool |
Vite |
| Language |
TypeScript (strict mode) |
| Routing |
React Router |
| Data fetching |
TanStack Query |
| Server state cache |
TanStack Query |
| Local state |
Zustand |
| Forms |
React Hook Form + Zod |
| Styling |
Tailwind CSS |
| Component primitives |
Radix UI / shadcn |
| Charts |
Recharts |
| Tables |
TanStack Table |
| Testing |
Vitest + React Testing Library + Playwright |
| Component docs |
Storybook |
- Initial JavaScript bundle: < 200 KB gzipped
- First Contentful Paint: < 1.5 s on 4G
- Time to Interactive: < 3 s on entry-level devices
- Lighthouse Performance: ≥ 90
- Lighthouse Accessibility: ≥ 95 (WCAG 2.1 AA target)
5.4 Internationalization & Accessibility
react-intl for translations- ICU MessageFormat for plurals, gender, lists
- Locale-aware date, currency, and number formatting
- RTL layout switching for Arabic
- WCAG 2.1 AA compliance: keyboard nav, screen reader, color contrast
- Currently shipped: English and বাংলা
6. Database — MySQL Cloud Enterprise
6.1 Why MySQL Cloud Enterprise
| Property |
Why It Matters for travoBooks |
| ACID compliance (InnoDB) |
Non-negotiable for a financial ledger — every journal entry must be atomic, consistent, isolated, durable |
| Proven at scale |
Deployed by Facebook, Uber, Booking.com, Airbnb — billion-row tables, thousands of TPS |
| Strong consistency |
Reads after writes are immediately consistent on the primary |
| Mature replication |
Async, semi-sync, and group replication for HA |
| Enterprise tier benefits |
Multi-AZ HA, PITR backups, encryption at rest (TDE), enterprise audit plugin, 24/7 SLA |
| Predictable performance |
Well-understood query planner, deterministic execution under load |
| Wide tooling |
DBAs, monitoring stacks, migration tools, and analytics integrations are all first-class |
6.2 Enterprise Tier Features Leveraged
- Multi-AZ high availability with automatic failover (< 60 s RTO)
- Point-in-time recovery (PITR) with 1-second granularity
- Read replicas for reporting workloads and disaster recovery
- Transparent Data Encryption (TDE) for at-rest protection
- MySQL Enterprise Audit plugin for tamper-evident logging
- MySQL Enterprise Backup for hot backups
- Thread Pool plugin for connection efficiency under heavy load
- 24/7 vendor support with defined SLAs
6.3 Schema & Data Design
- Multi-tenancy by partition: every business-meaningful table has
partner_id as part of the composite primary key
- Composite foreign keys
(partner_id, *_id) enforce isolation at the database layer
- Append-only financial tables (
journal_entries, journal_entry_lines, audit_logs) — no UPDATE, no DELETE
- Generated columns + functional indexes for JSON sub-fields
utf8mb4_0900_ai_ci collation for full Unicode (Bangla, Hindi, Arabic, emoji)
| Pattern |
Application |
| Connection pooling |
Per-service pool tuned to ~25 connections; ProxySQL for fan-in |
| Read replicas |
All reporting and analytics queries routed to replicas |
| Partitioning |
journal_entry_lines and audit_logs partitioned by month |
| Vitess (future) |
Horizontal sharding for partners exceeding single-instance throughput |
| Sharding key |
Always partner_id-first to keep tenant data co-located |
7. Cache & Queue — Redis
7.1 Why Redis
| Property |
Why It Matters for travoBooks |
| Sub-millisecond latency |
Hot-path reads (session, rate limit, idempotency keys) never block the user |
| Rich data structures |
Strings, lists, hashes, sorted sets, streams — one tool for many problems |
| Atomic operations & Lua scripting |
Safe counters, rate limiters, distributed locks |
| Streams |
Durable, partitioned, consumer-group queue for async jobs and event distribution |
| Pub/Sub & Keyspace Notifications |
Real-time signaling for WebSocket fan-out |
| Persistence options |
RDB snapshots + AOF for durability where needed |
| Cluster mode |
Horizontal scaling with automatic sharding |
7.2 Use Cases in travoBooks
| Purpose |
Redis Feature |
| User session storage |
Hash + TTL |
| API rate limiting (per partner, per IP, per token) |
Sorted set / token bucket via Lua |
| Idempotency keys for POST endpoints |
String + TTL (24h) |
| Distributed locks for booking holds |
SET NX EX + Redlock |
| Background job queue |
Redis Streams + consumer groups |
| Real-time notification fan-out |
Pub/Sub |
| Hot read cache (exchange rates, airport codes, fare rules) |
String / Hash |
| GDS request deduplication |
String + TTL |
| Webhook delivery queue with backoff |
Streams + delayed-job sorted set |
7.3 Operational Topology
- Redis Cluster with 6 nodes (3 primary, 3 replica) minimum
- Redis Sentinel for non-cluster deployments providing automatic failover
- AOF persistence with
appendfsync everysec for durability without major write penalty
- ACL for per-service credentials with command and key-pattern restrictions
- TLS in transit with mutual authentication
8. How the Components Interconnect
8.1 Steady-State Request Path
1. React SPA issues HTTPS request
2. CDN / WAF inspects, rate-limits, forwards
3. API Gateway (Go) authenticates via Redis session lookup
4. Gateway routes to the relevant service (Go)
5. Service applies business rules
6. Service reads cache (Redis) — on miss, queries MySQL
7. Service writes (if mutation): MySQL transaction
8. Service publishes events to Redis Streams
9. Asynchronous workers consume from Streams (notification, webhook, ledger)
10. Response returned to React SPA; WebSocket pushes downstream updates
8.2 Worked Example — Ticket Issuance
| Step |
Component |
Action |
| 1 |
React |
User clicks "Issue Ticket" → POST /v1/bookings/{id}/issue with Idempotency-Key |
| 2 |
API Gateway (Go) |
Validates session against Redis; checks rate limit |
| 3 |
Booking Service (Go) |
Acquires distributed lock in Redis on booking:{id} |
| 4 |
Booking Service (Go) |
Checks idempotency key in Redis — returns prior result if duplicate |
| 5 |
Booking Service (Go) |
Records "pending" in supplier_request_log (MySQL) and commits |
| 6 |
Booking Service (Go) |
Calls GDS / NDC outside the DB transaction |
| 7 |
GDS / NDC |
Returns ticket number |
| 8 |
Booking Service (Go) |
Opens MySQL transaction: INSERT ticket + INSERT JE lines + UPDATE booking state |
| 9 |
MySQL |
COMMIT (atomic across operational + ledger writes) |
| 10 |
Booking Service (Go) |
Publishes booking.issued event to Redis Stream |
| 11 |
Notification Worker (Go) |
Consumes event → renders e-ticket PDF → sends via AWS SES |
| 12 |
WebSocket Gateway (Go) |
Pushes status update to React SPA |
| 13 |
Booking Service (Go) |
Releases Redis lock |
This pattern — GDS call outside the transaction, ledger inside — is the central reliability principle of the platform. It is only possible because Go's concurrency model and Redis's lock primitives combine cleanly.
9. Scalability Considerations
9.1 Horizontal Scaling Profile
| Component |
Scaling Approach |
| Go services |
Stateless — scale out behind a load balancer with no coordination required |
| MySQL writes |
Vertically scale primary; route reads to replicas; shard by partner_id at extreme scale |
| MySQL reads |
Read replicas; replica count grows linearly with reporting load |
| Redis |
Cluster mode — automatic sharding across nodes |
| Background workers |
Stateless — scale with queue depth (Redis Streams pending count) |
9.2 Capacity Targets
- 10,000 concurrent users per region
- 1,000 transactions per second sustained
- 500+ journal entries posted per second at the ledger layer
- 99.95% uptime SLA
- Active-active multi-region (Phase 2 roadmap)
9.3 Auto-Scaling Triggers
- CPU > 70% for 3 minutes → scale out
- Request queue depth > 100
- p95 latency > defined SLO for 5 minutes
- Custom metrics: GDS error rate, queue lag
10. Enterprise Security
10.1 Defense in Depth
| Layer |
Controls |
| Edge |
WAF (rule-based + ML), DDoS protection, geo-fencing where required |
| Transport |
TLS 1.3 only, HSTS, certificate pinning for mobile clients |
| Authentication |
Argon2id-hashed passwords, MFA (TOTP), Personal Access Tokens, optional SSO (SAML, OIDC) |
| Authorization |
RBAC with maker-checker, scope-limited tokens, attribute-based policies |
| Service-to-service |
mTLS between every Go service; service identity via SPIFFE / Vault |
| Data at rest |
MySQL TDE, Redis with disk encryption, S3 with SSE-KMS |
| Data in motion |
TLS 1.3 between every hop |
| Secrets |
HashiCorp Vault or AWS Secrets Manager; automatic rotation; never in code or logs |
| Audit |
Append-only audit_logs with hash chaining; SIEM integration |
10.2 Compliance Alignment
- SOC 2 Type II — annual audit
- ISO 27001 — information security management
- PCI-DSS SAQ-A — by tokenizing card data via PCI-certified gateways (no PAN storage)
- GDPR / UK GDPR / DPDPA / PDPA — data subject rights, DPA agreements, EU SCCs
- Bangladesh ICT Act 2006 + Digital Security Act — local compliance for Bangladesh partners
- IATA / BSP — settlement integrity controls
10.3 Key Security Properties
- All Go services compile-time prevent SQL injection (parameterized queries enforced)
- React frontend uses Content Security Policy (CSP) + Trusted Types to block XSS
- Idempotency keys prevent double-spend and replay attacks
- Hash-chained audit logs detect tampering
- Maker-checker required for any operation above configurable thresholds
11.1 Latency Profile (p95 Targets)
| Operation |
Target |
| API authentication |
< 10 ms |
| Booking read (cached) |
< 30 ms |
| Booking read (cold) |
< 80 ms |
| Ticket issue (excluding GDS) |
< 200 ms |
| Journal posting |
< 50 ms |
| Report (cached) |
< 100 ms |
| Report (computed) |
< 5 s |
11.2 Throughput
- 1,000 RPS sustained per backend node
- 10,000+ RPS with horizontal scaling
- 500+ JE posts per second at the ledger
- 50,000 events per second through Redis Streams
11.3 Why This Stack Delivers
- Go's concurrency model eliminates thread-pool exhaustion under bursty traffic, allowing many simultaneous slow GDS calls without blocking the rest of the system.
- MySQL InnoDB with serializable isolation guarantees ledger integrity — the single most important property of a travel accounting platform.
- Redis at the front absorbs hot reads (sessions, rate limits, exchange rates) so MySQL only sees writes and cold reads.
- React's reconciliation algorithm keeps the UI responsive even when surfacing large ledger views and reconciliation tables.
12.1 Backend Workflow
- IDE: GoLand
- Linting:
golangci-lint
- Testing:
go test + testify + dockertest
- Migrations:
golang-migrate
- API spec: OpenAPI 3 (spec-first)
- CI: GitHub Actions
- Containerization: Docker
- Orchestration: Kubernetes (EKS / GKE)
12.2 Frontend Workflow
- IDE: VS Code
- Linting: ESLint + Prettier
- Testing: Vitest + React Testing Library + Playwright
- Build: Vite
- Component docs: Storybook
- CI: GitHub Actions
- Deployment: CDN with edge caching
12.3 Observability Stack
| Concern |
Tool |
| Metrics |
Prometheus + Grafana |
| Tracing |
OpenTelemetry → Tempo / Jaeger |
| Logging |
Structured JSON → Loki / OpenSearch |
| Error tracking |
Sentry |
| Uptime |
Pingdom / Better Stack |
| APM |
Datadog or New Relic (optional) |
13. Why This Stack — Summary Table
| Platform Requirement |
Selected Technology |
Why |
| High-concurrency GDS / NDC integrations |
Go |
Goroutines and channels handle thousands of simultaneous supplier calls |
| Financial ledger integrity |
MySQL Cloud Enterprise |
InnoDB ACID transactions, replication, TDE, audit |
| Real-time partner UI and dashboards |
React.js |
Virtual DOM, mature ecosystem, TypeScript safety, i18n |
| Sub-millisecond cache and queue |
Redis |
Multi-structure store, atomic ops, Streams for durable queues |
| Predictable backend developer experience |
GoLand |
Native Go intelligence, profiler, race detector |
Together, these four components deliver the latency, integrity, security, and scalability required by enterprise-grade travel accounting at global scale — while remaining operationally simple enough for a focused engineering team to run with confidence.