Designing Data Intensive Applications - Chapter 1 - thoughts and notes

Search for a command to run...

Can i also join the book reading club
One of the methods of abstraction is to integrate another service. But can you trust someone else's service? Third-party APIs are notorious for failing at the worst possible time. Over time, I ended u

A race condition can hit you anytime, you think it won't because your system isn't that big, or doesn't process a lot of requests, but it will happen, and when it happens, you will feel a bit silly ab

The world is going through a tumultuous phase, but that doesn't stop the progress of humanity. Things go on, people move, prices fluctuate, we eat fruit and live a healthy life. April is hot, so hot,

Well, I celebrated my birthday. :P I worked on a functionality end to end using AI. It was a simple feature and AI wrote everything correctly in a single pass. I used Codex. After that, I had to ask i

Let me think. So I worked on a new functionality and raised a PR in just 2 days for the whole end-to-end correct flow. I did not focus much on performance because I wanted to first get it right and th

I had been putting off reading DDIA for a long time, I usually gave up after reading 1-2 chapters, but now I have joined a book reading group where we are reading DDIA.
So I have company now and I am determined to finish reading the book.
Reading tech books always comes with a bit of friction. It reminds us of our school books ig.
Anyway, the first chapter was pretty straightforward. It was aimed at the basic blocks that define a good system.
The system should be:
Reliable
Scalable
Maintainable
Reliable.
When I say reliable what do I mean?
Well, it should run, reliably. I mean, it should function the way it is expected to. It should not shutdown abruptly if the user makes some mistake and it should prevent the misuse of its functions.
It should be fault tolerant. Fault tolerant means that if there is a hardware failure, software failure or human error then it should not willy-nilly stop performing its function or lose the data/user information.
A global outage can be excused, maybe? But in a nutshell, don't let the user down. your user is the most important key in the whole system.
Scalable
Now coming to Scalable, lets say we are working on a software prototype and we have built it. We post about it on Hacker News and suddenly we see a spike of user activity, the system should be able to deliver and perform efficiently when it happens.
You have to plan for building scalable systems, you have to think about the future scenarios. If you are a startup without PMF then maybe you can manage with hacks, but building a scalable system needs planning.
Scalability can be achieved in broadly three ways: Horizontal Scaling, Vertical Scaling and Elastic Systems.
The scaling efforts also depends on the problems you are facing and what kind of service/product you provide, the plans for handling scale can be a change in user flow, a change data flow or changing algorithms.
All solutions will end up with trade-offs. Plan and execute.
Also - you need to measure things to be able to come up with plans so use percentiles, measure response times and latencies. (p50, p90, p99, p999 - usually measured percentiles)
Maintainable
Maintainability means making the lives of your colleagues easier. The system you are building should be maintainable. For example, if someone new joins the team then he should be able to easily understand how things work and contribute to it.
Lets say the service went down, now to be able to restart it should be fairly easy and not rocket science. Your operations team should be able to perform certain functions and keep the service running smoothly.
A maintainable system abstracts away the complexity. The system should be simple.
All of this is my take away in a nutshell. :')