Web and Distributed Databases: Concepts and Worked Examples

A web database is typically a database that stores data and is accessed by web applications (HTTP/HTTPS requests) through an application backend (APIs, server-side code). The key idea is how the data is accessed (via web services) rather than how the data is physically distributed.

A distributed database extends this by placing data across multiple nodes (servers) and requiring coordination for queries, transactions, and consistency—often with replication and partitioning. It’s primarily about how the data is organized and managed across a network.

To connect them, consider a modern web app (e.g., an e-commerce site). The app’s front end uses web protocols, while the “database layer” may be:

• a single-node database (web app talks to one server), or
• a distributed database (web app talks to a distributed system that shards/replicates data).

Below, we use the same example (an online shop) to show both.

Concept map

Key learning terms (first seen):
web app , API , sharding , replication , transaction

Worked example: “Order history” in a shopping system

Assume users can:

1. browse products,
2. place orders,
3. view order history.

Case A — Web database (single-server database)

Flow

• Browser requests pages → backend API receives request → backend queries a single SQL database.
• The database may run on one machine (or one database cluster), but from the application’s perspective it’s one data endpoint.

Example

• User views /orders/12345
• Backend runs: “select order details where order_id = 12345”
• Response JSON is returned to the browser.

Mermaid view:

Characteristics

• Simpler coordination: one database system handles query planning and transactions.
• Scaling often relies on vertical scaling or a single “primary” database + read replicas (still usually presented as one logical system, depending on architecture).

Pro Tip: If all your database queries go to a single logical endpoint, you can call it a web database in practice—even though the DB engine might still have internal replication. What matters here is whether your data management across nodes is coordinated as a distributed database at the application/DB layer.

Case B — Distributed database (sharding + replication)

Now suppose the company stores orders across multiple servers to scale write throughput and storage.

Common design

• sharding by user_id or order_id range/hash.
• replication so reads can come from nearby replicas and for fault tolerance.

Example distribution:

• Shard A stores orders for user_ids whose hash starts with 0-3
• Shard B stores orders for 4-7
• Shard C stores orders for 8-9
• Each shard has 2 replicas.

Mermaid view:

Flow for order history

• User requests /orders (or /orders/12345)
• Backend sends the query to a coordinator/routing layer.
• The system sends sub-queries to the correct shard(s) and merges results.

Mermaid view (single order):

Flow (multi-order query) If the app asks for “orders from last 30 days” for a user, the query may hit only one shard (if sharded by user_id) or multiple shards (if sharded differently), requiring coordination.

Warning: Distributed queries and transactions can be more complex because coordination may require network round-trips and consistency decisions across nodes. This impacts latency and failure behavior.

Example comparison table (web DB vs distributed DB)

Key learning terms (second seen):
query routing , coordinator , failure tolerance , latency , consistency

Consistency intuition (why it matters for distributed DBs)

Distributed systems often discuss a tradeoff captured by the CAP theorem. The practical takeaway:

• With network partitions, you may have to choose whether the system prioritizes:
  • consistency (don’t return possibly stale data), or
  • availability (keep responding, possibly with stale data).

Even without naming CAP explicitly, distributed databases must implement some strategy for:

• what happens when replicas disagree,
• how long the system may take to converge, and
• how clients observe updates.