Learning Objectives – after this chapter you will be able to:
- Explain what makes an application centralized.
- Describe the client-server architecture with a front end, back end and database.
- List the advantages and the limitations of centralized applications.
- Explain why the “trust problem” of centralized systems motivated blockchain.
Centralized Applications
- Most Internet applications we use every day are centralized: a particular company or person owns the source code and runs it on its own computers, servers or server clusters.
- These are the applications that most engineers are used to building and most users are used to using – social networks, video platforms, online banking, e-commerce sites and e-mail services.
- The data lives in a centrally owned database controlled by that company. Users must ultimately trust that the company stores the data correctly, keeps it safe and acts in their interest.
- Even when a company runs thousands of servers in many countries, the application is still centralized because one organisation controls all of them.
Client-Server Architecture
Client (Front End)Browser or mobile app that shows the user interface.
Server (Back End)Business logic, authentication and APIs run by the company.
Central DatabaseAll user data stored and controlled by the same company.
Every request from a user (client) goes to the company’s server, which reads or writes the central database and sends back a response. The company can change the rules, the code or the data at any time.
Advantages and Limitations
| Advantages | Limitations |
|---|---|
| Fast performance – no need for many parties to agree. | Single point of failure – if the central server or data centre fails, the service stops. |
| Easy to build, update and fix bugs centrally. | Trust required – users must trust the operator with their data and money. |
| Clear accountability and customer support. | Censorship – the operator can block users or remove content. |
| Data can be edited or deleted when needed (e.g. privacy requests). | Data breaches – one central database is an attractive target for attackers. |
| Lower cost per transaction. | Opaque rules – users cannot verify how their data is processed. |
Centralization is not “bad”. It is the right design for most applications. Blockchain becomes interesting only when the trust and single-owner limitations above are a real problem.
Key Takeaways
- A centralized application is owned and operated by a single organisation that controls code and data.
- It is fast and simple but creates a single point of failure and requires users to trust the operator.
- Decentralized applications (next chapter) try to remove that single point of control.
Question / Answer (15 questions)
Answer : A centralized application is software owned and operated by a single organisation. Its code runs on servers controlled by that organisation and its data is kept in a database that the same organisation controls. Examples include typical social-media, video-streaming and online-banking services.
Answer : The front end (client) is the browser or mobile app that the user sees; the back end (server) runs the business logic and APIs; and the database stores the data. All three are controlled by the same organisation.
Answer : Because a single organisation still controls all those servers, the code and the data. Physical distribution of hardware does not remove the single point of control.
Answer : It is a component whose failure stops the whole system. For example, if a company’s central authentication server goes down, no user can log in to its service.
Answer : Users must trust the operator to store data correctly, protect it from breaches, process transactions honestly and not change rules unfairly. Users usually cannot verify any of this themselves.
Answer : High performance and low latency, simple development and maintenance with central control over updates, and clear accountability with customer support. They also make editing or deleting data straightforward.
Answer : Because one organisation controls the platform, it can suspend accounts, block transactions or remove content, either by its own policy or because it is required to by an authority.
Answer : All users’ data is in one place, so a single successful breach can expose millions of records. In a distributed design, there is no single repository holding everything under one set of credentials.
Answer : Yes, the operator can edit or delete records. It is not always bad – it allows correcting mistakes and handling privacy deletion requests – but it means users cannot be certain that history has not been changed.
Answer : The back end receives client requests, applies business rules, performs authentication and authorisation, reads and writes the database and returns responses to the client.
Answer : An internal HR system of a single company and a school’s attendance system. In both, one trusted organisation owns the data and needs fast, flexible updates, so a blockchain would add unnecessary cost.
Answer : In a centralized system a bank or payment company keeps the ledger and approves transfers. In a blockchain system the ledger is replicated across many nodes and transfers are validated by consensus rules instead of a single institution.
Answer : They do not need multiple independent nodes to validate and agree on every change. A single server can accept and commit a change immediately.
Answer : Users cannot inspect how the platform’s code processes their data or decides outcomes. Rules can be changed by the operator without users’ agreement.
Answer : Blockchain was designed to remove the need to trust a single intermediary. By replicating a tamper-evident ledger and using consensus, it removes the single point of control and failure that centralized systems have.
MCQ Test : Check Your Understanding (5 questions)
Select an option and press Check Answer, or answer all questions and press Submit Test to see your score. Each answer comes with an explanation.
Bibliography/References
The notes, questions and MCQs on this page are original explanations written for this course. The works listed below were consulted and are cited for attribution and further reading. Product names, logos and trademarks belong to their respective owners. Short quotations, where used, are marked and attributed.
- GeeksforGeeks. (n.d.). Centralized vs. Decentralized Applications. https://www.geeksforgeeks.org/centralized-vs-decentralized-applications/
- ethereum.org. (n.d.). Web2 vs Web3. Ethereum Developer Documentation. https://ethereum.org/en/developers/docs/web2-vs-web3/
- van Steen, M., & Tanenbaum, A. S. (2017). Distributed Systems (3rd ed.). distributed-systems.net. https://www.distributed-systems.net/
- Yaga, D., Mell, P., Roby, N., & Scarfone, K. (2018). Blockchain Technology Overview (NISTIR 8202). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8202