Denys Poltorak
2 min readMar 18, 2024

--

Some subdomain boundaries are strongly coupled and/or performance-critical. Take SQL databases. They are huge (25 MLoC reported https://news.ycombinator.com/item?id=18442941 ) and have several functionally distinct parts but distribution does not make sense. Let's peek under the hood. A SQL request goes through the next steps:

1) Receive a request and parse the protocol - some kind of Reactor or Proactor.

2) Lite tokenizer which removes any parameters and constants from the request.

3) The de-parametrized request is searched in a plancache - a hash-to-data map that contains fully processed requests that have been run previously.

4) If the request has not been found in the cache it needs to be parsed by some 20 KLoC Bison into a token tree.

5) The token tree is transformed into a DB's binary representation with pointers and cyclic references.

6) Metadata for the involved tables is linked in.

7) The now completed tree goes through an optimizer which toggles the order of joins based on table statistics found in the metadata.

8) Now the tree can be compiled into executable code.

9) Invilved indices are fetched.

10) The executable code is applied to the indices to filter out matching records.

11) Full records are read from storage.

12) Remaining filters are applied to the full data.

13) The resutls are output to the user.

14) Tables' metadata is updated.

15) The data is dumped to the drive and replicated if there were any writes.

So we clearly have a way for a functional division of a database by domain boundaries. Will such a database functionally distributed into 15 microservices have a good performance? What about paying for the traffic (sending the entire tables over the network)?

This shows an example of a monolith which cannot be made into microservices and remain usable. I hope this example is enough to prove that monoliths are distinguishable from microservices and that sometimes it's impossible to avoid chattiness.

--

--

Denys Poltorak
Denys Poltorak

Written by Denys Poltorak

yet another unemployed experienced embedded / low-level C++ technical lead from Ukraine

Responses (1)