doc_id: “FLYMAX-05-Strategy-TECH-STACK-ARCHITECTURE-DECISION-DOCUMENT” project_name: “FlyMax V2.0” title: “Technology Stack & Architecture Decision Document” doc_type: “Strategy” category: “Strategic Planning” version: “1.0.0” status: “active” scope: “valid” lifecycle_state: “active” created: “2026-03-09” updated: “2026-03-09” author: name: “George Joseph” role: “Technical Lead / Solution Architect” modified_by:
- name: “George Joseph” role: “Technical Lead / Solution Architect” date: “2026-03-09” approved_by:
- name: “” role: “” date: “” next_review_date: “2026-03-09”
Technology Stack & Architecture Decision Document
Flight platform — cost-effective MVP baseline with future AI readiness
1. Executive summary
Recommended baseline decision
- Use Next.js + TypeScript for the web surfaces and Fastify + TypeScript for the backend.
- Use PostgreSQL as the primary system of record. Do not adopt MongoDB-first only because vector search exists.
- Keep Redis optional. Add it only for caching hot reads or for BullMQ-style job processing.
- Start infrastructure cheaply: EC2-only for pilot, then EC2 + RDS for public launch, then ECS Fargate when scale and release cadence justify it.
- Treat AI as a later capability layer. Add pgvector on PostgreSQL first; avoid a second database until there is a real retrieval or model-serving need.
- Do not introduce Kubernetes, microservices, OpenSearch, or dual-database complexity in MVP unless a measured bottleneck proves the need.
Bottom-line recommendation
The cheapest serious architecture is a modular monolith:
Next.js + Fastify + PostgreSQL + optional Redis + Docker + Cloudflare
Use EC2 first, move the database to RDS early, and keep the path open for ECS Fargate later.
2. Context and evidence basis
The internal project documents already point to a cost-sensitive, phased architecture path rather than an overbuilt cloud platform.
- The approval register keeps MVP checkout redirect-only and positions direct booking/payment processing as future scope unless re-contracted.
- The change-log sheet recommends PostgreSQL as the system of record, keeps MongoDB as an evaluated alternative, and defers Kubernetes.
- The phase overview recommends EC2-only for pilot / early MVP, EC2-led with RDS for the next stage, and ECS Fargate later.
- The same material also emphasizes one backend service, one primary database, cache only hot reads, and queue slow work.
3. Decision criteria
| Criterion | Why it matters | Weight |
|---|---|---|
| Time to market | The project benefits more from getting a dependable MVP live than from architectural purity. | High |
| Operational cost | Early burn should stay low and predictable. | High |
| Operational simplicity | The team should be able to deploy, debug, and recover without platform specialists. | High |
| Relational fit | Bookings, audits, pricing rules, support, reconciliation, and reporting all create relational pressure. | High |
| AI readiness | The stack should support vectors and retrieval later without forcing premature complexity. | Medium |
| Scalability path | The architecture should scale by stages rather than by rewrite. | Medium |
| Vendor lock-in risk | Prefer choices with a clean exit path and standard tooling. | Medium |
4. Major option comparison
| Decision area | Option | Cost | Complexity | AI readiness | Verdict |
|---|---|---|---|---|---|
| Primary database | PostgreSQL + pgvector later | Low–Medium | Low | Strong | Recommended |
| Primary database | MongoDB Atlas only | Medium | Medium | Strong | Not default |
| Primary database | PostgreSQL + MongoDB together | High | High | Very strong | Reject for MVP |
| Infrastructure | Single EC2 + Docker Compose | Low | Low | Adequate | Pilot only |
| Infrastructure | EC2 app + RDS PostgreSQL | Low–Medium | Low | Strong | Public MVP default |
| Infrastructure | ECS Fargate + RDS | Medium | Medium | Strong | Growth stage |
| Infrastructure | Kubernetes / EKS | High | High | Strong | Defer |
| Jobs & queue | No queue | Low | Low | Weak | Only for tiny pilot |
| Jobs & queue | BullMQ + Redis | Medium | Medium | Neutral | Good if Redis exists |
| Jobs & queue | SQS | Low–Medium | Low | Neutral | Good managed option |
5. Database decision: PostgreSQL vs MongoDB vs dual-database
Why this decision exists
MongoDB now offers vector search and transactions, so it is reasonable to ask whether one document database could do everything.
The practical answer for this product is no — not as the MVP default.
Option comparison
| Option | Strengths | Weaknesses | Fit for this product | Cost view | Decision |
|---|---|---|---|---|---|
| PostgreSQL as primary; pgvector later | Strong joins, constraints, reporting, SQL analytics, mature operational model, easy fit for audit-heavy systems | Less flexible than a document model for highly irregular payloads; vector features are additive rather than the core identity | Best fit for bookings, payments, credits, rules, support, admin reporting, and reconciliation | Lowest total cost for MVP because one standard database covers most needs | Approve |
| MongoDB Atlas as primary and only database | Flexible schema, good operational fit for variable supplier payloads, Atlas Search and Vector Search available in one platform | Relational workflows and reporting become more application-driven; multi-document transactions exist but should not be treated as a free replacement for relational design | Usable, but better when the product is document-centric rather than governance-heavy | Usually acceptable, but cost-effectiveness weakens if the app must re-create relational guarantees in code | Keep as evaluated alternative |
| PostgreSQL + MongoDB from day one | Can optimize each storage shape independently; attractive on paper for AI plus operations | Highest cost, highest integration overhead, duplicated data contracts, more pipelines, more debugging surface, more migration risk | Overkill for MVP and the easiest way to create architecture churn before the product is validated | Most expensive in people-cost even if infra-cost looks manageable | Reject for MVP |
Decision logic
Use PostgreSQL as the system of record now. Add pgvector when AI retrieval becomes concrete.
Do not add MongoDB until there is a real workload that PostgreSQL handles poorly, such as:
- very high-volume semi-structured retrieval
- a separate AI knowledge workload
- an isolated document-centric subsystem with a clear boundary
6. Direct answer to the MongoDB question
- Yes, MongoDB Atlas Vector Search is real and usable for AI retrieval.
- Yes, MongoDB supports multi-document ACID transactions.
- But that does not automatically make MongoDB the best operational system of record for this platform.
- This product is not only “AI-ready search.” It is also pricing rules, booking state, reporting, auditability, support workflows, credits, approvals, and finance-linked history.
- For those workloads, PostgreSQL gives the simplest and most defensible default.
- The AI layer can be added later without changing the primary operational database.
7. Infrastructure decision: EC2 vs RDS vs Fargate vs Kubernetes
| Option | Best for | Pros | Cons | Budget view | Decision |
|---|---|---|---|---|---|
| Single EC2 box | Internal pilot, closed beta, early validation | Cheapest path, fastest setup, full control, simple backups and Docker Compose | Single point of failure; weak separation; not ideal for public growth | $ | Use only for pilot |
| EC2 app + RDS PostgreSQL | Public MVP and early growth | Keeps app simple while moving the most critical state to managed database infrastructure | Still some host management and scaling work on the app side | $$ | Recommended default |
| ECS Fargate + RDS | Frequent deployments, worker separation, cleaner scaling | No EC2 host management, better service isolation, cleaner autoscaling | Higher runtime cost and more AWS moving parts than EC2 | $$–$$$ | Adopt when needed |
| Kubernetes / EKS | Large platform team, many services, advanced orchestration needs | Very powerful and portable | Massive overhead for this stage; easiest way to overspend on operations | $$$$ | Defer |
Practical rollout
- Pilot: single EC2 with Docker Compose
- Public MVP: EC2 app + RDS PostgreSQL
- Growth: add ALB, second app instance, then move to ECS Fargate when deployment frequency and worker separation justify it
8. Queue and caching decision
| Option | Use when | Benefits | Tradeoffs | Decision |
|---|---|---|---|---|
| No dedicated queue | Very small pilot only | Lowest cost and simplest stack | Retryable work leaks into request path; poor failure isolation | Temporary only |
| BullMQ + Redis | You already need Redis for result caching or rate smoothing | Good JS developer experience; convenient retries | Redis becomes more operationally important | Good option if Redis exists |
| SQS | You want a managed queue with clean failure handling | Durable, dead-letter queues, less app-coupled than Redis jobs | Another AWS service and slightly less ergonomic than BullMQ | Strong managed option |
Cost-effective rule
Do not add Redis just because it is fashionable. Add it when:
- search/result caching is central
- BullMQ is the easiest path for retries
- notification, reconciliation, or report generation needs background processing
9. Search and AI capability decision
| Capability path | When to choose it | Pros | Cons | Decision |
|---|---|---|---|---|
| PostgreSQL + pgvector | You want one primary DB and AI is still early-stage | Simple architecture, relational consistency, vectors alongside operational data | Not the best fit for ultra-large dedicated semantic retrieval workloads | Recommended first step |
| MongoDB Atlas Vector Search | You already standardized on Atlas and your data is naturally document-centric | Vectors and semi-structured data in one platform | Does not remove the relational/governance complexity of the rest of the app | Valid alternative, not default |
| Dedicated vector DB later | AI retrieval becomes large, isolated, and performance-sensitive | Best specialized retrieval flexibility | Another system to operate and synchronize | Later only |
| OpenSearch / Elasticsearch from MVP | Heavy faceting, search engineering team, high query complexity | Powerful search features | Too much operational and financial weight for early MVP | Defer |
AI principle
Deterministic core first, probabilistic assist later.
Keep bookings, pricing, finance, and compliance surfaces deterministic. Use AI for:
- recommendations
- summaries
- ranking assists
- support tooling
- retrieval
…only after the event/data foundation exists.
10. Recommended tool stack matrix
| Tool | Purpose | Required level | Budget tier | Alternatives | Justification |
|---|---|---|---|---|---|
| Next.js + TypeScript | Consumer web, agent/admin portals, SEO pages | Must | Low | React + Vite, Nuxt | Best balance of SEO, routing, component reuse, and developer speed |
| Tailwind CSS | Fast UI styling system | Must | Low | MUI, Chakra, plain CSS | Keeps interface delivery quick and consistent |
| Fastify + TypeScript | Backend API and orchestration layer | Must | Low | Express, NestJS | Lean, fast, and suitable for modular-monolith design |
| PostgreSQL | Primary operational database | Must | Low–Medium | Aurora PostgreSQL, MySQL | Best fit for relational workflows, reporting, auditability, and finance-linked state |
| pgvector | Future semantic search / embeddings | Later | Low incremental | Atlas Vector Search, Pinecone | Lets AI arrive without changing the primary DB |
| Redis | Hot cache and/or job backend | Optional | Low–Medium | Valkey, Memcached | Only add when cache hit-rate or BullMQ use-case is real |
| BullMQ | Retries, notifications, reconciliation jobs | Optional | Low | SQS consumer workers | Great if Redis is already present |
| Amazon SQS | Managed queue | Should | Low–Medium | BullMQ | Clean managed queue for slow/retryable work |
| Docker | Packaging and environment consistency | Must | Low | Podman | Supports the EC2-to-Fargate migration path cleanly |
| Cloudflare | DNS, SSL, CDN, basic edge shielding | Must | Low | CloudFront, Fastly | Cheap performance and protection win |
| EC2 | Pilot runtime / early app host | Must | Low | Render, Railway | Cheapest serious start with full control |
| RDS PostgreSQL | Managed database stage | Should | Low–Medium | Self-hosted Postgres | Removes the highest-risk single point of failure first |
| ECS Fargate | Managed container runtime later | Later | Medium | EC2 autoscaling, Kubernetes | Adopt when deployment cadence or worker separation justifies it |
| GitHub Actions | CI/CD | Must | Low | GitLab CI, Bitbucket Pipelines | Good default for build, test, and deployment automation |
| CloudWatch + X-Ray / OpenTelemetry | Logs, metrics, traces, alarms | Must | Low–Medium | Datadog, Grafana Cloud | Enough visibility without premium tooling spend |
| GA4 / PostHog / Mixpanel | Product analytics | Should | Low–Medium | Amplitude | Required for funnel, CTR, and conversion learning |
11. What should be approved now vs later
| Now | Defer until justified | Reject for MVP | Reason |
|---|---|---|---|
| PostgreSQL as primary DB | MongoDB as second DB | Dual database from day one | Avoid needless data duplication and integration churn |
| EC2 pilot and EC2 + RDS public MVP | ECS Fargate | Kubernetes / EKS | Keep operations simple and cheap |
| One backend service / modular monolith | Microservices | Premature service decomposition | The bottlenecks are suppliers and queries, not service count |
| CloudWatch / basic OTel | Premium observability suites | No monitoring at all | You need enough visibility, but not enterprise spend |
| pgvector later | Dedicated vector DB | AI-first architecture before product validation | AI should follow real use cases, not drive the stack from day one |
12. Final recommendation
- Primary choice: Next.js + Fastify + PostgreSQL + optional Redis + Docker + Cloudflare
- Infrastructure: EC2-only for pilot, then EC2 app + RDS PostgreSQL for public MVP, then ECS Fargate later if justified
- AI path: start with deterministic event and analytics foundations, then add pgvector for retrieval and recommendation experiments
- Avoid MongoDB-first and avoid running Postgres + Mongo together in MVP
- Avoid Kubernetes, OpenSearch, and microservices until a measured bottleneck proves the need
Decision statement
Approve PostgreSQL as the system of record, approve the phased EC2 -> RDS -> Fargate infrastructure path, approve Docker and Cloudflare from day one, keep Redis optional, and treat AI/vector features as a later layer built on top of the core operational platform.
13. Evidence basis and source notes
Internal project documents
- Product Scope, Supply & Monetization Approval Register
- PRD v1.1 to v2.0 Change Log Sheet
- Flight Booking Platform PRD v3
- Phase 1 Overview notes
Vendor / official documentation
- MongoDB official docs: Atlas Vector Search overview; transaction production considerations
- AWS official docs: ECS Fargate overview; RDS PostgreSQL extension / pgvector support
Governance Footer
- Document ID: FLYMAX-05-Strategy-TECH-STACK-ARCHITECTURE-DECISION-DOCUMENT
- Canonical Version: 1.0.0
- Lifecycle: Active
- Scope: Valid
- Source of Truth: docs/
- Related Change Ticket:
- Last Reviewed On: 2026-03-09
- Next Review Due: 2026-03-09
Approval Sign-off
| Role | Name | Date | Status |
|---|---|---|---|
| Product Owner | Pending | ||
| Technical Lead / Solution Architect | George Joseph | Pending | |
| Engineering Lead | Pending | ||
| Commercial / Operations | Pending |
Document Lineage
- Supersedes:
- Superseded By:
Change Log
- 1.0.0 (2026-03-09) - Header/footer standardized to FlyMax documentation playbook.