Backend

For a long time, I’ve been concerned about deploying my containerized applications without downtime, ideally using Docker. While tools like Docker Swarm and various plugins offer solutions for this, I decided to explore something new (at least for me): Kubernetes. This post documents my journey into learning and using Kubernetes. Goal First I should make clear that the goal of this proof of concept is to run a simple NodeJS API application, and not to deploy a complete production environment using Kubernetes, as this might contain database, cache, queue and pub/sub services. ...

Balancing even distribution and query performance When using distributed databases, we generally encounter recommendations saying to distribute the data as even as possible. Imagine that we use a hash function to choose in which server we should store a record in. If we use an UUID as the primary key, that would be easy, and they will (in general) be evenly distributed. That works really well, and when you need, for example, to get the record #1, the database will reach few nodes to get that data (depending on the consistency level, some systems may query multiple nodes to detect newer versions). ...

When developing software at a higher level, communicating two systems is relatively easy. The go-to strategy is to use a HTTP client-server architecture probably exchanging content in JSON, and maybe using WebSockets. In this case, the only case we should handle is when a message fail being delivered, and when the connection is lost. Under the hood, the libraries and the operating system does a lot of to allow this communication. This article will detail some of these hidden operations discovered when developing a decentralized messaging app. ...

One of the first big errors a beginner programmer makes is to treat all HTTP requests as sequential. It’s easier to architect an application in which all the necessary actions occur in one single HTTP transaction. When there is only one client accessing the application it works fine, but it takes only one client generating a complex report to saturate the underlying machine. Again, this happens because a report in a real application won’t take seconds, but instead minutes or hours. ...