Morteza Sahragard

Designing Data-Intensive Applications is a book written by Martin Kleppmann. The paper version consists of 590 pages, and the audiobook is about 21 hours! So, get ready for a marathon if you choose the audio version!

I have to confess that since the past few years, video and audio trainings have become my main source of learning. Pluralsight, A Could Guru, Udemy, Coursera, YouTube, you name it!

Needless to say, one of the coolest features and biggest advantage of consumption based azure functions is the fact that how they scale out without we having to do anything about it. As of writing this post, consumption based functions can scale out up to 200 instances and premium ones up to 100. Apparently, if you need even more instances, that's also possible but you need to contact azure support team.

No matter what our strategy is to protect our resources and avoid accidental deletion, we should always be prepared for crisis management and know which steps to follow in case a disaster occurs. When it comes to disaster recovery, databases come on top of the list. Here we are going to discuss Azure Cosmos DB.

One of the biggest advantages of using Cloud services is the fact that we no longer need to maintain the Hardware and infrastructure. Using PaaS offerings takes it even further and we no longer need to care about updating services, applying security patches and so on.

While creating a container in Cosmos DB and also while upserting (insert/update) a document in the database, we can set a lifetime or so called Time to Live (ttl) to the documents. The lifetime is in seconds and the documents get deleted from the database after the given seconds are passed from the last modified time of the documents. But why would be a real use-case to leverage this feature?

A few words before starting the book review. I am big fan of Domain-Driven Design (DDD) and therefore, you can expect my review to be a bit opinionated. In a moment you will find out why.

I am dealing with a Azure Database for PostgreSQL now and a few days ago needed to export a database table with millions of records and import them in another table. As a person coming from Microsoft SQLServer world, I though it must have been a trivial work but in the end spent a couple of hours to figure out how to do that.