Architectures of Information Systems
0. Why architecture matters
Two applications can offer exactly the same features to the user and still be completely different systems. The difference is where the code runs, where the data lives, and how the parts talk to each other. That decision determines:
- how many users the system can serve,
- how fast it reacts,
- whether everybody sees the same data,
- how much it costs to operate and to update.
You cannot “add scalability later” - it is a consequence of the architecture you chose at the start.
0.1 Layer vs. Tier - do not confuse them
| Term | Meaning | Example |
|---|---|---|
| Layer | Logical separation of code | Presentation layer, business logic layer, data access layer |
| Tier | Physical separation, i.e. a separate machine/process | Client PC, application server, database server |
A program can have 3 layers and still be a 1-Tier system — if all three layers are compiled into one executable running on one machine. Layers = how you structure the source code. Tiers = how you deploy it.
The three classical layers:
+-----------------------------+
| Presentation (UI) | - what the user sees
+-----------------------------+
| Business Logic (Domain) | - rules, calculations, validation
+-----------------------------+
| Data Access / Storage | - SQL, files, DBMS
+-----------------------------+1. 1-Tier Architecture (Monolith)
All three layers run in one process on one machine. The database is not a server — it is a library linked into the application, working directly on a local file.
+------------------------------------------+
| One single machine |
| +------------------------------------+ |
| | Application process | |
| | UI -> Logic -> DB-Engine | |
| +-------------------------|----------+ |
| v |
| data.db (local file) |
+------------------------------------------+Typical technologies: SQLite, LiteDB, Microsoft Access (Jet/ACE), H2/Derby embedded, plain files (CSV/JSON/XML).
Typical use cases: desktop tools, mobile apps (SQLite is the standard store on Android and iOS), browser storage, measurement/logging software on a lab PC, caches, embedded devices, prototypes, single-user administration tools.
Advantages
- Simplest possible deployment: copy the program, done. No server, no DBA, no network.
- No network latency at all — a query is an ordinary function call (microseconds).
- Works completely offline.
- Still gives you real ACID transactions (SQLite does), just only for this one process.
- Cheapest to develop and to operate.
Disadvantages
- No shared data. Every installation owns its own truth. Ten users = ten different databases.
- Multi-user access is not possible in a safe way. A database file on a network share is a classic source of lock problems and file corruption.
- Scaling only vertically (buy a faster PC). There is nothing to scale out.
- Backup, updates and schema migrations must be done on every single machine.
- Data is only as safe as the end user’s device.
Note on the word “monolith”: in everyday language “monolith” describes an application whose code is one big deployable unit (as opposed to microservices). A monolith can very well run as a 2- or 3-Tier system. “1-Tier” is the stricter statement: everything, including the database engine, runs on one node.
2. 2-Tier Architecture (Client–Server)
The database becomes a server process on its own machine. The client (“fat client” / “thick client”) still contains presentation and business logic and talks to the DBMS directly over the database protocol (e.g. MySQL wire protocol via a driver / ADO.NET).
Client 1 Client 2 Client 3
+--------+ +--------+ +--------+
| UI | | UI | | UI |
| Logic | | Logic | | Logic |
| Driver | | Driver | | Driver |
+---|----+ +---|----+ +---|----+
| | | SQL over TCP (e.g. port 3306)
+---------------+---------------+
|
+-------------+
| DB Server | MySQL / PostgreSQL / SQL Server
| (DBMS) |
+-------------+Part of the business logic may be pushed into the DBMS as stored procedures, triggers and views — this is sometimes called a “2.5-Tier” system.
Advantages
- One central data store → single source of truth, real multi-user operation.
- The DBMS handles concurrency control, locking, transactions, users and rights for you.
- Much simpler to build than a 3-Tier system; very common in company LANs.
Disadvantages
- Every client holds its own database connection. Connections are expensive (memory, threads); a few hundred clients are usually the practical limit.
- Database credentials live on the client → a serious security problem. Anybody can attach a SQL tool to the server with those credentials and bypass your application logic completely.
- Logic updates require redeployment on every client.
- The client is tightly coupled to the database schema. Renaming a column breaks all clients.
- Chatty communication. Each SQL statement is one network round trip — painful over WAN/VPN (see the N+1 query problem).
- Not suitable for exposing the system to the internet.
3. 3-Tier Architecture (Client – Application Server – Database Server)
An application server is inserted between client and database. The client only does presentation, the application server owns the business logic and is the only component that talks to the database.
Browser / App Application Server(s) Database Server
+-------------+ +--------------------+ +----------------+
| Presentation| HTTPS | Business Logic | SQL | DBMS |
| (thin |------->| REST / gRPC API |------->| + storage |
| client) | JSON | Data Access Layer | pool | |
+-------------+ +--------------------+ +----------------+
(stateless, can be
replicated behind
a load balancer)You already know this: a Blazor WebAssembly frontend + ASP.NET Core Web API + MySQL is a textbook 3-Tier system. (Blazor WASM cannot open a MySQL connection from the browser at all — which is exactly why the middle tier exists.)
Advantages
- Horizontal scalability: if the application server is stateless, you simply start more instances behind a load balancer.
- Connection pooling: 10,000 users share maybe 50 database connections.
- Security: the database is not reachable from the internet; credentials stay on the server; the API exposes only the operations you allow.
- Central deployment of logic — one update, all users have it instantly.
- Clients are decoupled from the schema (they see a stable API, not tables).
- Room for caching, authentication, logging, rate limiting in the middle tier.
- Different client types (web, mobile, desktop) can share the same API.
Disadvantages
- More components → more complexity, more operations effort, more failure points.
- One additional network hop per request → higher latency than 2-Tier for a single operation.
- Requires thought about sessions/state, load balancing and deployment.
3.1 Outlook: N-Tier and microservices
The middle tier can be split further (API gateway, several services, message broker, cache tier). That leads to N-Tier architectures and microservices: maximum scalability and independent deployment, at the price of distributed transactions, network overhead and operational complexity.
3.2 Comparison
| 1-Tier | 2-Tier | 3-Tier | |
|---|---|---|---|
| Where is the logic? | client machine | client machine (+ DBMS) | application server |
| Where is the data? | local file | DB server | DB server |
| Multi-user | no | yes (limited) | yes (many) |
| Network latency | none | 1 hop | 2 hops |
| Scaling | vertical only | vertical (+ replicas) | horizontal (app tier) |
| Deployment of updates | per machine | per machine | central |
| DB credentials on client | – | yes (bad) | no |
| Internet-capable | no | no | yes |
| Complexity / cost | very low | medium | high |
| Example | SQLite mobile app | Access/WinForms + MySQL in LAN | Blazor + Web API + MySQL |
4. Metrics for comparing architectures
Architectures are not “good” or “bad” — they are trade-offs. Three metrics are used to discuss them.
4.1 Data consistency
Do all users see the same, correct data at the same time?
- Within one DBMS, consistency is guaranteed by ACID transactions (Atomicity, Consistency, Isolation, Durability).
- 1-Tier: ACID inside one installation, but zero consistency between installations — every copy has its own version of the truth.
- 2-Tier / 3-Tier with one central DB: strong consistency, one single source of truth.
- Replicated/distributed systems: copies must be synchronized. With asynchronous replication a reader on a replica can see stale data (replication lag) → eventual consistency.
CAP theorem (short): in a distributed system that suffers a network Partition you can keep either Consistency or Availability, not both.
4.2 Scalability
Does the system still work when load grows — and what does it cost?
- Vertical scaling (scale-up): bigger machine. Simple, but limited and expensive; the only option for a 1-Tier system.
- Horizontal scaling (scale-out): more machines. Requires a stateless tier or a way to partition/replicate data.
- Rule of thumb: the stateless application tier scales out easily, the stateful database tier is the hard part. Typical DB techniques: read replicas (scales reads), sharding/partitioning (scales writes), caching.
- Measured as speed-up (same work, n times the hardware → how much faster?) and scale-up (n times the work and n times the hardware → same response time?). Ideal = linear; reality is worse because of coordination, skew and startup costs.
4.3 Data latency
The word is used with two different meanings — know both:
- Response latency: how long a single request takes. Local function call (1-Tier) ≈ µs · LAN round trip ≈ 0.2–1 ms · WAN/internet round trip ≈ 20–200 ms. Latency adds up per round trip, so 100 single-row queries in a loop cost 100 round trips (the N+1 problem) — always prefer one join/batch statement.
- Data freshness / staleness: how old is the data I am reading? Caches (TTL), asynchronous replicas (replication lag), nightly ETL into a data warehouse (hours). Latency here is measured in seconds, minutes or hours, not milliseconds.
4.4 The trade-off
Consistency
/\
/ \
/ \ You can optimize two of them easily.
/ \ The third one will fight back.
/________\
Scalability Latency| Consistency | Scalability | Latency (response) | |
|---|---|---|---|
| 1-Tier | ACID locally, none globally | very poor | best possible |
| 2-Tier | strong (central DB) | poor–medium | good (1 hop) |
| 3-Tier | strong (central DB) | good (app tier) | medium (2 hops) |
| Distributed DB, sync replication | strong | good | worse (commit waits for all nodes) |
| Distributed DB, async replication | eventual | very good | very good (local read/write) |
5. System architectures of database systems
The tier model describes the application. Now we look inside the data tier itself.
5.1 Centralized database
One DBMS instance manages one logical and physical database on one server (possibly with a hot standby for failover).
many clients ---> [ single DBMS ] ---> storage- + simplest consistency (all ACID guarantees, no distributed transactions), simple administration, backup, monitoring; joins are cheap because all data is local.
- – single point of failure; hard limit on throughput; scaling only vertically; all users pay the network latency to that one location (bad for globally distributed users).
- Still the right answer for the vast majority of business applications. Do not distribute until you must.
5.2 Distributed databases
Data is stored on several nodes/sites that are connected by a network, but appear to the application as one logical database.
Design decisions
- Fragmentation (partitioning):
- horizontal — split by rows (e.g. customers A–M on node 1, N–Z on node 2). Also called sharding. This is what scales writes.
- vertical — split by columns (rarely used, e.g. rarely-needed BLOB columns on a separate node).
- Replication: keep copies of the same fragment on several nodes.
- synchronous: commit only when all copies acknowledge → strong consistency, higher latency.
- asynchronous: commit immediately, replicate afterwards → low latency, stale reads possible.
- primary/replica (one writer) vs. multi-primary (several writers → conflict resolution needed).
- Allocation: which fragment/replica is placed where (ideally close to the users who need it).
Transparency is the central quality criterion: the developer should write ordinary SQL without knowing where the data physically is. Location transparency, fragmentation transparency, replication transparency.
Distributed transactions spanning several nodes need a coordination protocol, classically 2-Phase-Commit (2PC):
Phase 1 (prepare): Coordinator --"can you commit?"--> all nodes
nodes write their changes durably and answer YES/NO
Phase 2 (commit): all YES -> "COMMIT" to everyone
any NO -> "ABORT" to everyone2PC guarantees atomicity but is slow (two round trips + fsync) and blocking: if the coordinator dies between the phases, the participants keep their locks and wait.
- + scale-out, fault tolerance (node failure ≠ total failure), data locality → low latency for local users, can satisfy legal requirements (“EU data stays in the EU”).
- – high complexity, distributed joins are expensive (data must be shipped across the network), consistency becomes a design decision, difficult debugging and backups.
Example - MongoDB:
A replica set is replication, a sharded cluster is
horizontal fragmentation with a router (mongos) providing location transparency.
Other examples: MySQL/MariaDB Galera Cluster, PostgreSQL + Citus, Cassandra, Google Spanner.
5.3 Parallel DBMS
A parallel DBMS also uses many processors/nodes, but with a different goal: not geographic distribution, but raw performance for one big workload. The nodes sit in one data center, connected by a very fast interconnect, and are administered as one system.
Hardware architectures
Shared Memory Shared Disk Shared Nothing
CPU CPU CPU CPU CPU CPU CPU CPU CPU
\ | / | | | | | |
[ RAM ] +----+----+ RAM RAM RAM
| | | | |
[ Disk ] [ Storage ] Disk Disk Disk
\____|____/
interconnect| Shared Memory | Shared Disk | Shared Nothing | |
|---|---|---|---|
| Idea | all CPUs share RAM + disk | own RAM, shared storage (SAN) | each node owns RAM + disk |
| Scaling | poor (memory bus) | medium | very good (linear) |
| Complexity | low | medium (cache coherence) | high (data partitioning) |
| Example | classic multi-core server | Oracle RAC | Teradata, Greenplum, BigQuery, Snowflake |
Shared Nothing is the architecture of choice for large analytical systems, because there is no shared bottleneck resource.
Forms of parallelism
- Inter-query parallelism: different queries run on different processors (helps throughput, e.g. many OLTP users).
- Intra-query parallelism: one query is split up (helps response time of one big query).
- inter-operator: different operators of the query plan (scan / sort / join) run in parallel, often as a pipeline.
- intra-operator (data parallelism): the same operator runs on different data partitions — the most effective form.
Data partitioning strategies: round-robin (even distribution, bad for lookups), hash (perfect for equality lookups and joins), range (good for range queries, risk of hot spots).
Why speed-up is never perfect: startup costs (starting n processes), interference (nodes compete for shared resources), skew (one partition is much bigger → everybody waits for the slowest node).
5.4 Distributed vs. parallel
| Distributed DBMS | Parallel DBMS | |
|---|---|---|
| Primary goal | availability, locality, autonomy | performance (throughput, response time) |
| Nodes | geographically separated sites | one machine room, fast interconnect |
| Network | WAN, slow, unreliable | LAN/interconnect, fast, reliable |
| Administration | possibly several autonomous administrations | one system, one administration |
| Homogeneity | may be heterogeneous | homogeneous hardware & software |
| Typical workload | OLTP, global applications | OLAP, analytics, data warehouse |
6. Summary — choose the architecture
- Single user, offline, local data → 1-Tier with an embedded DB (SQLite).
- Small team, trusted LAN, few users → 2-Tier is often enough.
- Internet, many users, several client types → 3-Tier. Default choice today.
- One database server too slow / not available enough → first read replicas and caching, then distribution (sharding).
- Huge analytical queries → parallel, shared-nothing DBMS.
Engineering rule: take the simplest architecture that satisfies your requirements. Every additional tier and every additional node costs latency, money and debugging time.
8. Self-check questions
- Explain the difference between a layer and a tier using one concrete example.
- Your app has 3 layers and runs entirely on a notebook with SQLite. How many tiers is that? Why?
- Name two reasons why 2-Tier systems are not used on the public internet.
- Which tier of a 3-Tier system scales horizontally most easily, and what is the precondition?
- What is the N+1 problem and which metric does it damage?
- Give the two meanings of “data latency” with one example each.
- Why does synchronous replication improve consistency but hurt latency?
- Explain horizontal fragmentation and name a system you know that does it.
- Describe the two phases of 2PC. What happens if the coordinator crashes in between?
- Compare shared-disk and shared-nothing in one sentence each.
- Why is linear speed-up rarely reached in a parallel DBMS? Name two reasons.
- A company wants a global app with low latency in Europe, the US and Asia, and can accept that data is a few seconds old. Which architecture do you propose, and which metric do you sacrifice?
Short answers
- Layer = logical code structure, tier = physical deployment node. A WinForms app with a
UI,ServicesandRepositoryproject has 3 layers but is deployed as 1 tier. - 1-Tier — presentation, logic and the database engine all run in one process on one machine.
- Database credentials would have to be stored on the client, and the DB port would have to be open to the internet; additionally every client would need its own connection.
- The application tier, provided it is stateless (no session data held in the instance).
- Fetching a list (1 query) and then one query per element (N queries) instead of a single join/batch → N+1 network round trips → response latency explodes.
- (a) Response time of one request (ms). (b) Staleness of data, e.g. a replica 3 s behind or a data warehouse loaded nightly.
- The commit only returns after all copies confirmed → all copies are identical (consistency), but the transaction takes as long as the slowest node (latency).
- Splitting a table by rows across nodes (sharding), e.g. a MongoDB sharded cluster or customers A–M / N–Z on two servers.
- Prepare: coordinator asks all nodes, they persist and vote YES/NO. Commit: all YES → COMMIT, otherwise ABORT. If the coordinator crashes after prepare, participants are blocked and hold their locks until it recovers.
- Shared disk: each node has own RAM but all share the storage (cache coherence needed). Shared nothing: every node owns its RAM and disk and only exchanges messages — scales best.
- Startup costs, interference on shared resources, and data skew (one oversized partition).
- Distributed database with regional nodes and asynchronous replication (or a CDN/cache layer). Sacrificed metric: strong consistency → eventual consistency / stale reads.