October 2018 – Shekhar Gulati

Database Isolation Levels And Their Effects On Performance And Scalability: 10 mins read. It is always good to refresh the foundational concepts. This post covers database isolation levels:
1. Read Uncommitted: This level allows one transaction to read uncommitted data written by another transaction. This isolation level allows dirty reads.
2. Read Committed: This level allows one transaction to read data committed by another transaction. PostgreSQL uses READ COMMITTED as the default isolation level.
3. Repeatable Read: This level ensures that during a transaction you are guaranteed to read the same data that were committed when the transaction was started even if you make multiple read calls. MySQL uses this level as default.
4. Serializable: This isolation level ensures that all transactions occur in a completely isolated fashion, meaning as if all transactions in the system were executed serially, one after the other.
How Sharding Works: 20 mins read. Database sharding is a complex topic to master. There are so many database and they all handle sharding differently. This post gives a good introduction to sharding and different ways sharding is implemented by different databases.
1. Algorithmic sharding: This is implemented at the client side using an algorithm like hash(key) % number of servers in the database cluster
2. Dynamic sharding: This is implemented using a locator service. Clients make call to locator service and it tells them which node to talk to.
3. Entity groups: This approach stores related entities in the same partition to provide additional capabilities with in a single partition. This is a popular approach to shard a relational database.
4. Hierarchical keys and Column-oriented databases
How One Website Exploited Amazon S3 to Outrank Everyone on Google: 20 mins read.
The interesting ideas in Datasette: 15 mins read.
More than 9 million broken links on Wikipedia are now rescued : 10 mins read.
Kubernetes for personal projects? No thanks! : 10 mins read. The article goes over reasons why you shouldn’t run Kubernetes cluster for a small project. I agree with the point. Your goal should be to build application rather than fighting with infra. I found Docker compose based deployment sufficient for my side projects. I provision a docker machine on AWS and then deploy containers using Docker compose. It works great when you are small. I think the same argument for Microservices and Monolithic applications. Don’t use Microservices architecture for small projects.
Rate limiting for distributed systems with Redis and Lua: 15 mins read. This post explains how you can implement API rate limiting in your application. It shows how to do that using Redis and Lua scripts. It covers two use cases for API rate limiting 1) rate limiting upstream clients and rejecting calls above the limit 2) rate limiting downstream clients to ensure that they can maintain allowed calls per second.It uses Token Bucket and Leaky bucket algorithms to meet the use cases.
A brief history of High Availability: 20 mins read. This article covers the history of how databases have evolved to support availability and consistency. It covers Active-Passive, Active-Active, and Multi-Active approaches to design available database clusters.