Headstart to the Internals of a Database

masrur alam — Fri, 30 Oct 2026 20:34:21 +0000

On a general note, a Database Management System (DBMS) is known to us as a structured means for data storage and retrieval. However, if you dive slightly into the internals, you will encounter the fascinating realm of a carefully designed system. Comprising several useful subsystems, it ensures the request and retrieval of data leveraging text-based query languages.

So, how does a query written in some query language return the intended result? Understanding DBMS architecture would be a great starting point in this regard.

Database management systems utilize a client-server model, where the application instance is the client and the database system instance takes the role of the server. The four core subsystems of the whole architecture and the overall flow are mentioned as follows:

1. Transport Subsystem: establishes communication between client and server. Requests come in the form of queries written in a query language.

2. Query Processor Subsystem: The query is handed over to the query processor, which comprises a query parser and query optimizer. The former checks, validates, and interprets the query upon parsing, while the latter creates the most efficient execution path, known as the query plan, possible from the available plans by making use of the parsed query.

3. Execution Engine: Thirdly, the execution engine takes the query plan as input and runs it to request the intended data from the database.

4. Storage Engine: Consisting of several necessary components named lock manager, transaction manager, buffer manager, and recovery manager, the storage engine maintains structured storage for data organization and access on disk via heap files or B-trees. In addition, the buffer manager caches data for faster in-memory data access while disk remains the persistent storage. The transaction and lock manager work as the means for concurrency control, while the system state is restored by the recovery manager from the previously maintained logs in case of system crash or failures.

Once the data is successfully retrieved, it passes through the reverse direction, all the way to the transport subsystem and finally reaching the client.

Such enlightenment on the inner workings of a DBMS has shown that every request and response is not merely some query-based operation but an important indication of a data-specific, informed, engineered system.

System design: When great solution comes with great problems

masrur alam — Wed, 28 Oct 2026 09:58:40 +0000

System design is the overall architecture planning of a software system comprising different core components with a prime a focus on ensuring an effective balance between the expected outcome and newly added constraints. Such balance usually leads to systems which we often call reliable, scalable, and maintainable.

Before ending up with something like the above, always answer these 5 simple questions first:

What the system does? Who does it serve?
How many users and the growth rate?
Read-heavy or write-heavy application?
What thing/things you can never lost?
How much latency as well as cost is affordable?

A clarity on the above issues smooths your understanding of the business requirements and start at least with planning.
However, there is no concrete solution to a system design problem since it is influenced by the answers to the mentioned questions which with several other edge cases known as functional and non-functional requirements. This is what makes such problem more interesting where you have some tools to plug and play with while system-level analytical thinking being the most critical factor.

In addition, a solution to the problem is to add a new problem. For example, adding caching may make rapid retrieval of frequent data but adds to the careful consideration of eviction strategies. Or, you may think that adding several horizontally scaled servers would solve your problem but adding a single more powerful server (vertical scaling) would have solved the problem. So, these are the design choices that comes with thinking and understanding the core requirements. You design a system, you reduce the single point of failure, identify where the system can break, you solve it, all okay but a new complexity, you go again. So, there is never ending aspect to it.

This is something that makes software system design fascinating; at least what I have perceived so far exploring it from the high level.
And as far as the 5 above question, the answers will be caught somewhere in the next posts.

DEV Community: masrur alam

Headstart to the Internals of a Database

System design: When great solution comes with great problems