langbuana.com — Cloudflare-Only Travel Discovery Plan

Goal

• Build langbuana.com as a global travel discovery site for places to visit, not property listings.
• Run the production path on Cloudflare only: Pages, Workers, D1, R2, KV, Queues, Cron Triggers, Analytics Engine, and optionally Durable Objects.
• Pre-ingest and normalize place data into first-party storage so the live site is fast, cacheable, and not dependent on third-party API latency for normal reads.

Reuse Decision

• Reuse sewakamar.com only as an infrastructure starting point.
• Keep: Wrangler setup, Worker routing pattern, D1/KV/R2 bindings, asset serving approach, and Cloudflare-first deployment model.
• Replace: schema, API semantics, search model, UI copy, SEO structure, ranking logic, and all room/owner/WhatsApp workflows.
• Do not keep the current monolithic room schema because it encodes the wrong business model.

Product Shape

• Core entity is place, not room.
• A place can be a country, region, city, landmark, attraction, neighborhood, route, beach, mountain, museum, park, island, or festival area.
• Primary user flows:
• browse by continent/country/city/category
• search destinations and attractions
• open a place detail page
• view nearby related places
• view editorial lists like "Best places in Kyoto for spring"
• optionally save favorites or build simple itineraries later

Recommended Cloudflare Architecture

• Pages: static shell, route assets, editorial pages, sitemap files.
• Workers: API, SSR fragments, search endpoints, feed endpoints, webhooks, signed asset URLs, ingestion admin routes.
• D1: normalized travel catalog, editorial metadata, import logs, taxonomy, rankings.
• R2: place hero images, gallery derivatives, source dumps, import snapshots, generated JSON exports.
• KV: edge cache for hot list pages, search suggestions, country/city landing payloads, route metadata.
• Queues: ingestion jobs, image processing jobs, enrichment jobs, reindex jobs.
• Cron Triggers: scheduled syncs, cache refresh, popularity rollups, stale-source rechecks.
• Analytics Engine: search analytics, page popularity, click-throughs, source freshness metrics.
• Durable Objects: only if needed for write serialization, ingestion locks, or rate-controlled source polling.

Data Model

• places
• place_names
• place_types
• place_categories
• place_category_links
• place_hierarchy
• place_locations
• place_sources
• place_images
• place_descriptions
• place_tags
• country_index
• city_index
• popularity_rollups
• editorial_guides
• editorial_guide_places
• ingest_runs
• ingest_errors

Suggested places Core Fields

• id
• slug
• canonical_name
• short_description
• long_description
• country_code
• admin1
• city_name
• lat
• lng
• geohash
• place_kind
• source_primary
• source_ref
• rating_internal
• popularity_score
• image_cover_key
• status
• created_at
• updated_at

Source Strategy

• Use a hybrid source model instead of relying on one provider.
• Split source concerns:
• administrative geography and city hierarchy
• destination discovery and POIs
• editorial description and enrichment
• images and media

Recommended Source Stack

• GeoNames for countries, admin areas, cities, alternate names, and base geographic hierarchy.
• Wikidata for entity identity, multilingual names, official links, coordinates cross-check, and structured facts.
• Wikipedia / Wikivoyage / Wikimedia GeoSearch for editorial context and nearby discovery.
• OpenTripMap for travel-oriented POIs and attraction discovery on a global basis.
• OpenStreetMap-derived data as the underlying open geography layer, but not the public Nominatim endpoint for production bulk usage.

Source Roles

• GeoNames

• best for continent -> country -> region -> city scaffolding

• good for alternate spellings and multilingual search seeds

• suitable for initial D1 seed imports

• Wikidata

• best for deduplication and cross-source identity

• use as the canonical external entity graph

• useful for mapping the same place across GeoNames, OpenTripMap, Wikipedia, and Wikivoyage

• Wikipedia / Wikivoyage

• best for human-readable summaries and travel context

• use for snippet generation and related editorial pages

• do not depend on it as the only structured source

• OpenTripMap

• best for POI and attraction lists around cities or coordinates

• good MVP source for "things to do nearby"

• can be cached and stored after ingestion

• OSM / Nominatim

• use carefully

• public nominatim.openstreetmap.org should not be treated as your production geocoder for heavy traffic or bulk ingestion

• if geocoding volume grows, switch to a commercial Nominatim provider or your own hosted pipeline outside the request path

MVP Recommendation

• Phase 1 data:

• GeoNames dump for country/admin/city hierarchy

• Wikidata for place identity and multilingual aliases

• OpenTripMap for attraction inventory and coordinates

• Wikipedia/Wikivoyage snippets for summaries

• Phase 1 scope:

• 50 countries

• 500 cities

• 20,000 to 100,000 attractions

• category pages like beach, mountain, museum, old town, family trip, food street, island

Search and Ranking

• Search should be first-party, not runtime-dependent on external APIs.
• Ingest aliases and names into D1 and precompute suggestion payloads into KV.
• Ranking inputs:
• exact name match
• alias match
• country and city popularity
• editorial boost
• click-through rate
• freshness
• source confidence
• geographic proximity if user shares location

Location-Aware UX

• Use browser geolocation only after user consent.
• Resolve the user to a coarse location, then surface:
• nearby attractions
• nearest cities
• nearby airports or gateways later
• same-country recommendations
• Do not make third-party geocoder calls directly from the browser.
• Browser calls should hit your Worker, then Worker uses cached or normalized first-party data.

SEO Structure

• /
• /continent/[slug]
• /country/[slug]
• /city/[slug]
• /place/[slug]
• /category/[slug]
• /guides/[slug]
• /near/[country-or-city]
• Pre-render high-value routes.
• Generate XML sitemaps by country and content type.
• Store SEO JSON payloads or rendered fragments in KV for hot pages.

Ingestion Pattern

• Cron triggers fetch source manifests or delta jobs.
• Queue fan-out processes place batches.
• Worker normalizes records and writes to D1.
• Media fetchers copy approved images into R2.
• Import metadata and failure rows go into D1.
• Cache refresh jobs update KV payloads for hot pages.

Security and Ops

• No Hetzner runtime in the serving path.
• Secrets only via Wrangler secrets.
• Protect admin ingestion routes with Cloudflare Access.
• Add WAF and rate limiting to search endpoints.
• Use source attribution storage per place so license obligations are auditable.

Key Constraints

• D1 is good for catalog and search metadata, but not for storing giant raw source dumps as-is.
• Keep raw dumps and snapshots in R2, store normalized relational slices in D1.
• Avoid Worker-time fanout to many upstream APIs on page load.
• Cloudflare-only runtime is realistic, but source ingestion is still dependent on external data providers.

Practical Answer To "100% CF"

• Yes for hosting, application runtime, storage, cache, jobs, and delivery.
• No if interpreted as "all data also originates from Cloudflare". Your data must still come from external geographic and travel sources.
• The right interpretation is:
• Cloudflare serves and stores everything in production
• external sources are used only for controlled ingestion and refresh

Build Sequence

• 1. Fork sewakamar.com structure into langbuana.com.
• 2. Replace room schema with place schema.
• 3. Remove room/owner/WhatsApp flows.
• 4. Build country, city, place, and category APIs.
• 5. Add ingestion pipeline for GeoNames + Wikidata + OpenTripMap.
• 6. Add static/detail pages and sitemap generation.
• 7. Add search suggestions and popularity rollups.
• 8. Bind langbuana.com domain on Cloudflare Pages/Workers routes.

First Implementation Cut

• Worker app with:

• GET /api/search

• GET /api/countries

• GET /api/cities?country=

• GET /api/places/:slug

• GET /api/nearby?lat=&lng=

• GET /api/categories

• Data bootstrap:

• import top countries

• import top cities

• import first batch of attractions

• import one cover image per place where licensing permits

Decision

• The sewakamar.com template is reusable as an infrastructure skeleton.
• It is not reusable as a domain model.
• For global place data, the best source mix for an MVP is:
• GeoNames
• Wikidata
• Wikipedia/Wikivoyage
• OpenTripMap
• and OSM-derived data used through controlled ingestion, not public Nominatim as a heavy production dependency

⚙ HARD CONSTRAINTS (enforced for all sites)

This domain MUST operate within these constraints — no exceptions:

• 100% Cloudflare serverless — Workers + D1 + R2 + KV + Workers AI + Vectorize. NEVER PM2, NEVER VPS, NEVER Docker in production path.
• 100% AI-automated — every customer interaction, every moderation decision, every transaction reconcile = AI. No manual queue, no live human chat support, no physical fulfillment.
• 1-operator solo — one person can run the entire operation from a phone. No team meetings, no shared inbox, no shift rotation.
• WhatsApp AI bot for all support (24/7, instant response, no SLA promises that need humans).
• Mayar QRIS for all Indonesian payments (subscription auto-renew, no manual invoicing).
• Indonesian UI primary — bahasa-first, English fallback only where unavoidable.
• Privacy — opt-in only, delete-on-request honored within 24h (cron-driven).
• No physical goods, no inventory — digital products + affiliate referrals only.

If the plan above describes any flow that violates these constraints, treat the plan as ASPIRATIONAL only and rework before building. The constraint trifecta wins.