At a high level, web application servers are relatively simple to describe. They execute the core business logic that handles a user’s request and sends bac HTML to the user’s browser. 

To do their job, they typically communicate with a variety of backend infrastructures such as databases, caching layers, job queues, search services, other microservices, data/logging queues, and more. As mentioned above, you typically have at least two and often times many more, plugged into a load balancer in order to process user requests.

Every modern web application leverages one or more databases to store information. Databases provide ways of defining your data structures, inserting new data, finding existing data, updating or deleting existing data, performing computations across the data, and more.

In most cases the web app servers talk directly to one, as will the job servers. Additionally, each backend service may have it’s own database that’s isolated from the rest of the application.

A caching service provides a simple key/value data store that makes it possible to save and lookup information in close to O(1) time. 

Applications typically leverage caching services to save the results of expensive computations so that it’s possible to retrieve the results from the cache instead of recomputing them the next time they’re needed. An application might cache results from a database query, calls to external services, HTML for a given URL, and many more.

• Job queues store a list of jobs that need to be run asynchronously. The simplest are first-in-first-out (FIFO) queues though most applications end up needing some sort of priority queuing system. Whenever the app needs a job to be run, either on some sort of regular schedule or as determined by user actions, it simply adds the appropriate job to the queue.
• Job servers process jobs. They poll the job queue to determine if there’s work to do and if there is, they pop a job off the queue and execute it. 

It leverages an inverted index to quickly look up documents that contain the query keywords.

The most popular Full-Text search platform today is Elasticsearch though there are other options such as Sphinx or Apache SOLR. 

Full-text search leverages an inverted index to quickly look up documents that contain the query keywords.

Once an app reaches a certain scale, there will likely be certain “services” that are carved out to run as separate applications. 

They’re not exposed to the external world but the app and other services interact with them. 

Today, companies live and die based on how well they harness data. Almost every app these days, once it reaches a certain scale, leverages a data pipeline to ensure that data can be collected, stored, and analyzed. A typical pipeline has three main stages:

1. The app sends data, typically events about user interactions, to the data “firehose” which provides a streaming interface to ingest and process the data. 
2. The raw data as well as the final transformed/augmented data are saved to cloud storage. 
3. The transformed/augmented data is often loaded into a data warehouse for analysis. 

The technology provides a way of serving assets over the web much faster than serving them from a single origin server. It works by distributing the content across many "edge" Servers around the world. In general a web App should always use a CDN to serve CSS, Javascript, images, videos.

And that’s a wrap on Web Architecture 101. I hope you found this useful. I’ll hopefully post a series of 201 articles that provide deep dives into some of these components over the course of the next year or two.