A music portal tied to a radio station generates very uneven traffic, and its architecture follows from that constraint. The editorial home page produces predictable requests; the community — chat, forum, webmail — produces spikes tied to what is on air. When a track plays and the host invites listeners to the site, simultaneous connections climb within seconds. Sizing for average traffic means falling over at precisely the moment the site is needed.

Context

The reference model is the portal built around a station’s music brand: editorial content (artist pages, reviews, schedule) and a set of services that turn a passive listener into a registered user. It is the latter that weigh. A static or near-static editorial page is served in milliseconds; a chat with a few hundred connected users keeps connections open, polls continuously, and touches the database on every message. On a community portal the ratio between read requests and interaction requests leans towards the latter far more than the page-view count would suggest.

The typical platform in 2004 sits on Linux, Apache and a server-side language — for this kind of site PHP is the commonest choice — with a relational database (MySQL or PostgreSQL) behind it. On top there is a content management system, custom or semi-custom, that separates the editorial desk from the markup. Pages are generated conforming to XHTML 1.0 (W3C Recommendation, Second Edition, August 2002), with presentation handed off to CSS: a model already workable at this date on the common browsers, the known rendering differences notwithstanding.

Architecture

The unit of service is a server farm, not a single machine: several identical application nodes behind a balancer, with the database and storage shared downstream. The reason is twofold. The first is capacity: no single Apache node holds up under the spikes described above, and placing nodes in parallel scales horizontally better than growing one machine. The second is continuity: with two or more nodes, the loss of one does not bring the site down.

Balancing, at this date, is done at different layers. The simplest form is round-robin DNS: several A records for the same host name, and the client’s resolver picks one. It works, but it distributes badly, because DNS caching on the client and on intermediate resolvers keeps users pinned to one node and knows nothing of server state (Red Hat, Virtual Server Administration). The more solid form is a network-level balancer in front of the farm: the Linux Virtual Server project, with its IPVS kernel modules, routes packets to the real nodes using round-robin or weighted round-robin scheduling, and can pull a failed node out of rotation. It moves the load at packet level, and costs far less in CPU than application-level forwarding.

For the community services, where one can, one leans on already-mature software. For the forum the de facto standard is phpBB 2.0, released in April 2002 (phpBB History) and adopted everywhere. For webmail on user accounts the mature options are SquirrelMail — version 1.4.0 of 3 April 2003 added CRAM-MD5/DIGEST-MD5 authentication and TLS for IMAP and SMTP (SquirrelMail ChangeLog, v1.4.0) — and Horde/IMP, both interfaces over an underlying IMAP/POP3 server. Chat, by contrast, is rarely found ready in the form one needs: a radio portal’s community wants a chat hooked into the site login and moderable by the editorial desk, and that one usually writes oneself.

The critical point

The point where these systems break is session state. If an authenticated user moves from one node to another between requests — which the balancer may do on every hit — their session must be visible on the new node. Keeping sessions in each node’s local files does not hold: the user loses their login the moment they are routed elsewhere. In 2004 there are two workable paths. The first is the sticky session: configuring the balancer to nail a client to the same node for the whole visit; simple, but it worsens distribution and reopens the continuity problem if that node fails. The second is to centralise state — sessions in the shared database, or in a dedicated store — so that every node sees the same truth; it costs one extra write per request but makes the nodes genuinely interchangeable.

Chat sharpens exactly this problem, because it is the most stateful service in the portal: long-lived connections, frequent updates, message ordering that must stay consistent across users served by different nodes. That is why chat, more than the forum or the webmail, conditions the choices about the rest of the farm.

Implications

One practical consequence concerns statistics. With traffic spread across several nodes, the logs no longer sit in one place, and counting visits and audience means gathering and consolidating them — far from free when on-air spikes inflate the volumes. Audience measurement, which for a radio-linked portal has direct commercial value, therefore depends on the discipline with which the farm’s logs are centralised and de-duplicated.

A second consequence concerns caching. Editorial pages, which change rarely, can be served from cached copies without touching the application on every request; separating the cacheable part (editorial) from the non-cacheable part (authenticated community) is what lets the nodes absorb the spikes without multiplying machines. The separation between content and community, which at the editorial level is a product choice, at the infrastructure level is the main lever of scalability.

Limits

These notes describe what can be kept standing with the tools common as of March 2004, not an architecture that is optimal in the absolute. Network-level balancing with IPVS asks for non-trivial systems skill and a balancer node that must itself be made redundant, otherwise one merely relocates the single point of failure. Centralising session state on the shared database moves the bottleneck onto the database, which becomes the resource to protect. And ready-made community software — phpBB, SquirrelMail, Horde — carries its own maintenance and security surface, which on a high-visibility site is not negligible. Every choice above is a trade-off, and which branch is worth taking depends on the real traffic profile, which on a radio-linked portal you genuinely know only after the first spikes.

A concrete case of this architecture — the unitedmusic.it portal built by noze for the Radio 105 group around the InFlow CMS, with chat, forum, webmail and server-farm management — is taken up in an insight published by noze: https://www.noze.it/en/insights/united-music-portal/.

https://www.w3.org/TR/xhtml1/ https://www.phpbb.com/about/history/ https://squirrelmail.org/docs/phpdoc14/ric_ChangeLog.html https://www.horde.org/apps/imp/ https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/4/html/virtual_server_administration/s1-lvs-scheduling-vsa https://www.unitedmusic.it

Cover image: Metal rack filled with stacked Compaq servers, cabling and a NAS storage array in a server room — photo by Jemimus, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Compaq_server_rack_-_IMG_0146.jpg