![Igor Šarčević](https://operately.com/_astro/igor.CWS1MLnE.jpg)
I saw something insane on LinkedIn today. A founder bragging about his co-founder about submitting a pull-request during his own wedding. Let that sink in for a moment.
When I started working in the industry, I thought I knew what hard work...
We’ve recently witnessed a perfect example of this parasitic behavior. A startup, freshly minted by a once-respected incubator, had the audacity to fork an open-source project and claim it as their own. They didn’t innovate. They didn’t improve...
From the moment we’re born, our time isn’t really our own. Parents, schools, and later, employers all have a say in how our days unfold. As kids, we’re on someone else’s schedule. Education systems beat it into us, training us to march to...
We are actively developing Operately, an open-source software licensed under Apache 2.0. As such, we need to carefully consider whether our dependencies’ licenses are compatible with ours. Starting to build features based on functionality...
When engineers want to introduce a change to the system, they use pull requests to package the change and present it to the rest of the team. A pull request usually contains a title, a description, and a list of commits that aim to change...
With the microservice architecture style, services and their data are contained within a single bounded context. This architectural decision helps us to develop and deploy changes in one business unit fast and independent of other services...
Receiving a request, saving it into a database, and finally publishing a message can be trickier than expected. A naive implementation can either lose messages or, even worse, post incorrect messages.
Let’s look at an example. A user registration...
Killing processes in a Unix-like system can be trickier than expected. Last week I was debugging an odd issue related to job stopping on Semaphore. More specifically, an issue related to the killing of a running process in a job.
Last week I was debugging a weird bug in one of our services. In the logs we saw an SQL error “repetition-operator operand invalid”, so I was pretty sure that we have a broken SQL comparison in one of our services. The weird part was that this error happened only occasionally, seemingly randomly.
Last week we’ve investigated a way to achieve stable pagination for our new API. I’ve learned some new techniques for handling pagination, and dig deep into the downsides of standard — offset based — pagination.
Recently I switched my ISP provider and with the change I’ve got a new WiFi router. The download speed is incredible, 10x the compared to my previous subscription, but the stability got worse.
Slow database queries harm your organization in many ways. They can damage the reputation of otherwise great applications, make background processing painfully slow, and drastically increase the cost of your infrastructure. As a seasoned web developer, it is absolutely essential to learn about optimization strategies for your data layer.
In concurrent systems where resources are locked, two or more processes can end up in a state in which each process is waiting for the other one. This state is called a deadlock. Deadlocks are an important issues that can happen in any database and can be scary when you encounter them for the first time.
The most prominent feature of PostgreSQL is how it handles concurrency. Reads never block writes, and writes never block reads. To achieve this, PostgreSQL uses the Multi Version Concurrency Control (MVCC) model, an elegant solution for a very hard problem. If you want to design highly concurrent applications, you should really invest the time to understand the bits and bolts of this mechanism.
Misunderstanding transaction isolation levels can lead to disgusting side effects in your application. Debugging such issues can be more than painful. The SQL standard defines four levels of transaction isolation. Each of these isolation levels defines what happens if two concurrent processes try to read data updated by other processes.
A regular select statement does not give you enough protection if you want to query data and make a change in the database related to it. Other transactions can update or delete the data you just queried. PostgreSQL offers additional select statements that lock on read and provide an extra layer of safety.
PostgreSQL provides the means for creating locks with application defined meaning. These locks are called Advisory Locks and are an ideal candidate for concurrency control where the standard MVCC (multiversion concurrency control) doesn’t fit the bill. Advisory Locks can be the perfect tool in your arsenal when you need to control access to a shared resource in a distributed system.
Locking is an important topic in any kind of database. Without properly handling locks, an application might not only be slow, it might also be wrong and behave in some insane ways. Therefore, learning proper locking techniques is essential for good performance and correctness of our applications.
I have learned an important lesson this year. A clear separation between queries and commands can bring a lot of long term benefits to your code.