Chapter 0.4 — Technology Stack

1. Purpose

This chapter inventories every technology in travoBooks' production stack: language runtimes, frameworks, datastores, infrastructure components, libraries, observability tooling, and supporting services. It serves as the canonical reference for new engineers, security reviewers, vendor due-diligence, and operations runbooks. When a chapter elsewhere references "the cache layer" or "the queue worker", the concrete component is defined here.

2. Why it matters in modern travel accounting

Travel-accounting platforms are unusual: they combine high-volume transactional workloads (booking inserts at airline-network latency), strict financial integrity (double-entry posting must not lose a single line), and integrations with legacy XML-heavy systems (GDS, BSP, IATA portals). Stack choices are constrained by these forces — for example, the operational database and ledger must share a single ACID transaction for issuance to be safe, which is why the platform uses a relational RDBMS rather than a polyglot persistence layer.

3. Industry relevance

The stack favours boring, well-understood components over novelty. Auditors recognise MySQL and standard SQL; insurers and banking partners ask familiar questions about TLS, KMS, and DR; engineers can join the team without learning bespoke languages. Travel-tech specifically benefits from PHP's mature SOAP / XML tooling — necessary for Amadeus, Sabre, and Travelport legacy endpoints — without forcing the platform onto an obscure runtime.

4. Compliance considerations

• PCI DSS — payment card data never lands in the application DB; gateway tokens only. The stack section on cardholder-data boundary is enforced at the integration layer (see Volume 7).
• GDPR / data-protection — encryption at rest (AES-256 on EBS/S3/RDS), encryption in transit (TLS 1.2+ exclusively), key custody via cloud KMS with rotation.
• SOC 2 / ISO 27001 readiness — every stack component emits structured logs to a central WORM-retained log store; immutable audit trail is preserved for ≥7 years.
• IFRS 15 / IAS 21 enforcement at code level — the JE engine is the only path from operational state to the ledger; the stack does not expose direct SQL writes to the GL.

5. Stack inventory

5.1 Application runtime

PHP was chosen because (a) the founding team has deep PHP expertise, (b) the Amadeus / Sabre SOAP toolchain is mature in PHP, (c) hosting costs are low, and (d) the codebase already runs cleanly on PHP 8+ with strict types. Future hot paths may be extracted to compiled services but the monolith remains PHP.

5.2 Web tier

.htaccess style URL hiding (per platform UX preferences) is implemented by Nginx try_files rules; .php extensions never appear in client-facing URLs.

5.3 Database tier

travoBooks uses a single primary database for operational + financial data. This is deliberate: it guarantees that booking issuance and journal-entry posting occur in one transaction, removing the entire class of "ledger drift" bugs that plague distributed-database designs in travel.

5.4 Cache & queue

5.5 Object storage

5.6 Search

5.7 Email & messaging

5.8 Frontend

The UI uses a server-rendered, progressive-enhancement model — chosen for predictability, accessibility, low operational overhead, and because financial UIs benefit from the simplicity of submit-and-redirect patterns.

5.9 Integrations layer

5.10 Observability

5.11 Security stack

5.12 Infrastructure

6. Module dependencies

The technology stack is the substrate for every module in the platform. No module bypasses these layers — direct database access from controllers is forbidden; all DB writes go through the persistence layer (see Volume 1), and all ledger writes go through the JE engine (see Volume 5).

7. Security & permissions

Every stack component runs with least privilege. The application database user has DML on operational tables but no DDL; schema changes go through a separate migration user. The cache and queue Redis instances are isolated network-wise from public ingress. S3 buckets are private with KMS-managed encryption; access is scoped per partner via prefix-based IAM policies in Phase 2.

8. Validation rules (deployment checklist)

9. Common pitfalls (⚠️)

• ⚠️ Do not introduce a second OLTP database. Any "side store" that holds financial state becomes a reconciliation problem. Side stores are acceptable only for read-only projections (search, analytics, cache).
• ⚠️ Do not write to the ledger outside the JE engine. SQL INSERT INTO journal_entries from a controller is a serious bug — bypasses balance check, dimension validation, period state, FX capture.
• ⚠️ Do not bypass the queue for slow integrations. Synchronous GDS calls inside a request can exceed timeouts; always queue-and-poll for long-running supplier operations.
• 🔒 PCI scope. PAN data must never enter the application database. If a feature appears to require storing PAN, route through the gateway tokenisation flow instead.

10. Future scalability

• Phase 2 — extract the read-heavy reporting layer to OpenSearch + materialised views on the replica.
• Phase 3 — move BSP / supplier-import workers to a separate cluster (Kubernetes-managed) for elastic batch scaling.
• Phase 4 — partner-id-based sharding of the primary DB when a single partner approaches 5M bookings/year or the total transaction volume exceeds the headroom of vertical scaling.
• Phase 5 — optional read-only GraphQL layer for partner-built dashboards.

The stack does not plan to migrate languages or break the monolith for the sake of architectural fashion. Changes are driven by measured limits, not by trend.