7.4Typical System Architectures

The HA, scalability, and cloud building blocks from earlier sections combine, in real web services, into a handful of recurring patterns. This section centers on the LAMP/LAPP stack and the three-tier web model that LinuC has long emphasized, and rounds up the standard combinations used to make them redundant and fast.

7.4.1LAMP/LAPP and the three-tier web model

• LAMP stands for Linux (OS) + Apache (web server) + MySQL/MariaDB (database) + PHP/Perl/Python (application language). LAPP swaps the database to PostgreSQL (Linux + Apache + PostgreSQL + PHP/Perl/Python); the web server is still Apache. The only difference is the database (MySQL/MariaDB vs PostgreSQL). Both are proven, all-open-source reference stacks.
• The three-tier web model splits processing into a web tier (serving static content, accepting requests), an application tier (running business logic), and a database tier (persisting data). The chief benefit: each tier can scale and be made redundant independently (e.g., scale out only the web tier, or scale up only the DB tier onto beefier hardware).

7.4.2Standard patterns for redundancy and speed

• For redundancy: the web/application tier sits behind a load balancer with multiple instances, scaled out as needed. The database tier achieves HA through database replication (a primary plus multiple replicas—spreading reads across replicas while failing over to a replica if the primary fails). Each tier uses a different redundancy strategy suited to its role.
• For speed: a proxy server (sits between client and server, relaying requests; a reverse proxy sits on the server side and often also load-balances and terminates SSL), a cache (reuses previously computed results, avoiding redundant work), and a CDN (content delivery network—serves static content from geographically distributed points of presence, answering from a location close to the user with low latency).
• Asynchronous data processing via a message queue: heavy work that does not need an immediate answer—image conversion, sending email, aggregation jobs—is placed on a queue and processed in turn by backend workers. The web server can respond without waiting for that work to finish, improving the response time the user actually experiences.

Walk through building a real service to see the whole picture. Suppose a blog service launches on a LAMP stack (Linux, Apache, MySQL, PHP). As traffic grows and one web server becomes slow, the three-tier idea splits the web tier from the database tier onto separate machines, and the web/application tier scales out behind a load balancer. At this point the load balancer itself becomes a SPoF, so making it redundant too (active-standby) is standard practice. A single MySQL instance becomes both a write bottleneck and a single point of failure, so the database tier moves to replication—one primary, several replicas—spreading read queries across replicas while keeping a failover path ready: if the primary fails, one replica is promoted to the new primary (sometimes automated with Pacemaker). Static files like images and CSS are then served from a CDN to offload the origin servers, and data that is read often but rarely changes (say, aggregated home-page stats) goes into a cache so the same computation is not repeated. Heavy work that the user need not wait for—generating thumbnails for an uploaded image, say—goes onto a message queue, processed asynchronously by backend workers, while the web server immediately returns an "accepted" response. This progression—from a plain LAMP starting point, to per-tier redundancy, to cache/CDN speedups, to decoupling via async processing—is exactly the shape of a typical system architecture, both in practice and on the LinuC exam.

7.4.3Section summary

• LAMP = Linux + Apache + MySQL/MariaDB + PHP/Perl/Python; LAPP uses PostgreSQL for the DB (same Apache web server). The three-tier model scales and is made redundant per tier
• Web/app tier = load balancer + scale-out; DB tier = replication + failover. CDN, cache, and async queues deliver speed and decoupling