Architecture & Data Flow

How the public website, admin panel, API, worker, and data stores fit together — and how a request and a piece of content move through the system.

The shape of the system

There are two front-end applications — the public website and the admin panel — and both talk to a single core REST API. The API owns all business logic and data access. A separate worker process, sharing the API codebase, runs scheduled and queued background work. Behind the API sit three data stores (MongoDB, Redis, OpenSearch) and a set of external service integrations.

Edge & domains

CloudFlare sits in front of the platform. The public website serves every town on its own subdomain of macaronikid.com (for example national.macaronikid.com). The API and admin panel each have a dedicated host.

Request flow: a public pageview

When a visitor opens a town page:

• The request hits CloudFlare, then the Apache/PHP web server (web2), which resolves the town from the subdomain and renders the page server-side.
• web2 calls the REST API (API_ROOT = api.macaronikid.com/api/v1) for the content it needs — articles, events, directory, guides.
• On render, the page fires a lightweight tracking call to statistic/trackView on the API, which records the hit in the TownViewCount collection in MongoDB. This is the source of the pageview numbers shown in the admin panel.

Content flow: publishing an article

• A publisher creates or edits an article in the admin panel, which writes it through the API into MongoDB (the Article model).
• The API indexes the article into the Article OpenSearch domain so it is searchable across the network.
• Articles can be cloned and shared to other towns (original, cloned, opt-in, must-share, opt-out), and rolled into newsletters.
• The worker handles scheduled publication and newsletter generation on cron schedules, and reconciles any failed search indexing.

Where the logic lives