Backend Architecture & Cloud Cost Plan

Executive summary

This addendum sizes LCB ONE's backend (§5 of the main proposal) for full-load operation — 15,000–20,000 trucks/day across Laem Chabang's 18 terminals — and turns that into a concrete infrastructure bill. The headline finding: at this volume, LCB ONE is a mid-sized transactional and real-time-tracking system, not a hyperscale one. Peak sustained throughput lands around 90–150 events/second and roughly 1,300–1,500 trucks tracked live at once — comfortably inside what a right-sized managed-Kubernetes stack handles without exotic engineering.

Full-load cloud infrastructure runs an estimated ฿306,000–720,000 per month (indicative), or under ฿1.2 per truck processed. The larger, less controllable cost line is not cloud compute — it's payment-gateway transaction fees and SMS fallback messaging, both usage-based, negotiated outside engineering, and covered in §6.

Sizing the load

"15,000–20,000 trucks/day" is a volume figure, not a load figure. To size infrastructure honestly, it has to be translated into events per second, concurrent connections, and storage growth — using the reservation lifecycle and location-ping design already defined in the main proposal (§5.1–§5.3).

2.1 Events per truck, at full load (20,000/day)

~1.26M events/day averages to ~15 events/sec around the clock. Real traffic isn't flat: assuming the two gate-rush windows the main proposal's root-cause analysis already identifies (§3) carry roughly 35% of daily volume in about 4 hours combined, sustained peak throughput lands around 90–150 events/sec. Concurrently, at a peak arrival rate of ~2,000 trucks/hour and a ~40-minute average EN_ROUTE window, ~1,300–1,500 trucks are being GPS-tracked and holding a live connection at the same moment — the number that actually sizes the real-time layer, not the daily total.

2.2 Storage growth

Even after a full year at full load, the hot operational dataset stays well under 100 GB with a 90-day GPS-ping window — comfortable headroom for a mid-tier managed Postgres instance for several years of growth before resizing.

Reference architecture

Mapping the four layers already defined in the main proposal (§5) onto concrete, managed cloud services, right-sized to the throughput in §2. AWS service names are used as the primary reference; GCP/Azure equivalents are noted in parentheses since the final vendor is a data-residency decision (§9), not just a technical one.

Capacity & scaling plan

Linear-scaled from the full-load baseline in §2, against the same four roadmap phases from the main proposal (§7):

Monthly cloud cost model

Indicative planning-level figures for the full-load production environment (Phase 4, §4), in a mid-tier public-cloud Southeast Asia region. Low = reserved/committed pricing, lean sizing; High = on-demand headroom, premium support. See §10 for what these figures are — and aren't.

Other costs to budget

The cloud infrastructure bill in §5 is not the whole picture. Two more categories scale with truck volume or are simply necessary to run the platform responsibly.

6.1 Usage-based third-party services

6.2 Non-infrastructure operational costs

• Platform engineering / SRE run-cost — the people who own uptime, on-call, and capacity planning; not a cloud line item, but required to run any of the above.
• Commercial APM/observability licensing — if a premium tool (Datadog/New Relic) is chosen over self-hosted Prometheus/Grafana, add roughly ฿540–900/host/month on top of §5's observability line.
• Annual security penetration test & PDPA compliance support — a one-time-per-year professional-services cost, material given the GPS-tracking and payment data in scope (§9).
• Quarterly DR test exercises — validating the pilot-light standby in §5 actually fails over, not just that it's provisioned.
• Training & change management — for Port Authority control-tower staff, terminal operations console users, and LSP/trucking onboarding.
• Support/maintenance contract with the implementing vendor/integrator, beyond the initial build.
• Contingency buffer — recommend 15–20% on top of the §5 total for any board-level budget submission.

Cost optimization levers

• Reserved instances / savings plans for baseline compute and the database — typically 30–50% off on-demand pricing once steady-state is confirmed at Phase 3–4.
• Spot instances for stateless, interruption-tolerant workers — GPS-ping ingestion and notification fan-out are both good fits.
• Autoscale burst node pools to near-zero outside the gate-rush windows identified in §2.1 — the load is not flat, and the infrastructure shouldn't be provisioned as if it were.
• Self-host the routing engine for the ETA engine (§5.3 of the main proposal) instead of a pay-per-call maps API — the port's road network is a small, static graph, well suited to OSRM/GraphHopper. This alone avoids the ฿72,000–126,000/month line in §6.1.
• LINE-first notification strategy over SMS — consistent with the driver app's LINE Mini App channel already proposed (see the Driver app, three platforms page) — keeps the far more expensive SMS line in §6.1 small.
• Archive, don't hoard, GPS pings — 90 days hot in the operational DB (§2.2), then move to cheap object storage. Keeps the primary database small and fast instead of accumulating an unbounded LocationPing table.
• Serverless-first for Phases 1–2 (Aurora Serverless v2, managed Fargate, serverless message-broker tiers) so Phase 1–2 doesn't pay for full HA capacity before the load in §4 justifies it — migrate to the provisioned sizing in §5 as Phase 3–4 is reached.

Phased cost ramp

Cloud infrastructure cost tracks the roadmap in §7 of the main proposal, not a single full-load number from day one — applying the optimization levers in §7 above most aggressively in the earlier phases:

Data residency & compliance

LCB ONE handles personal data in scope of Thailand's PDPA — driver names and phone numbers, GPS location (§5.3 of the main proposal), and license-plate/vehicle data. Because the Port Authority is a state enterprise, the cloud vendor decision in §3 may not be purely technical: Thai government IT-governance policy (DGA guidelines) may call for GDCC (the government's own data center/cloud service) or an accredited private-cloud provider for some or all workloads, rather than a public hyperscaler by default.

If a public-cloud path is preferred with in-country data residency, an Asia Pacific (Bangkok) region is now a realistic option from major providers, alongside the long-standing Singapore region used for the cost figures above. Either way, this is a decision for the Port Authority's IT governance and legal teams to confirm early — it can change both the vendor and the §5 cost figures materially, and shouldn't be assumed by default.

Assumptions & caveats

• Figures in §5 and §8 are order-of-magnitude planning estimates built from public list-price patterns for a mid-tier public-cloud Southeast Asia region — not a vendor quotation. Actual pricing depends on region, negotiated enterprise discount, committed-use terms, and instance sizing confirmed by a real load test.
• All figures are shown in Thai Baht. Source cloud list pricing is typically US-dollar-denominated internationally; the indicative ~36 Baht per US dollar planning rate used to convert it is a rounded assumption only — reverify the live exchange rate and current list pricing at the time a budget is actually submitted.
• This page covers recurring run-rate cost only — one-time build/integration effort is scoped separately in the main proposal's roadmap (§7) and is not estimated here.
• Recommend validating §5 against a formal cloud-provider TCO calculator and an actual load test before committing budget — the sizing in §2 is a design-time estimate, not a measured result.
• Payment-gateway and SMS costs (§6.1) are pass-through/variable and require direct vendor negotiation — they are not controlled by the architecture choices in §3 and are flagged, not estimated with confidence, for exactly that reason.