Skip to main content

My experience with the Golden signals

In June 2022, I embarked on a quest for a new job opportunity. Fortunately, this endeavor began just before the global job market experienced a significant downturn. I must admit, I faced my fair share of rejections during this period, but I also had an epiphany. It became evident that there was so much more to learn and understand in the world of technology.

Coming from a small service-based company, I had encountered limitations in terms of how much I could learn on the job. However, during interviews and conversations with senior developers, I gained valuable insights into the architectural and technical decisions made by teams in various companies.

One such company that left a lasting impression on me was Delivery Hero. Their technical blog posts provided a wealth of information, especially for someone like me, transitioning from a smaller company where projects had minimal daily active users compared to the scale of Delivery Hero.

One particular blog post that caught my attention was "The Delivery Hero Reliability Manifesto" authored by Christian Hardenberg. I initially started reading it to prepare for interviews and to better understand how Delivery Hero operated in the realms of technology and operations. Little did I know that this read would introduce me to the concept of "Golden Signals."

For a developer who was just starting their journey, the idea of Golden Signals was nothing short of eye-opening. Monitoring and logging were concepts I had previously underestimated. Yet, when it comes to developing a service used by millions, understanding the significance of these four Golden Signals is paramount.

The four Golden Signals are latency, traffic, errors, and saturation. I won't delve too deeply into them, as you can find a comprehensive explanation in the provided link. However, monitoring these four metrics can make a world of difference when navigating the complexities of developing a microservice.

  • Latency: This measures the time it takes for a service request to be processed.
  • Traffic: It signifies the demand placed on your service.
  • Errors: As the name suggests, this relates to the rate of failure.
  • Saturation: This indicates how "full" your system is in terms of I/O, memory, storage, and more.

For those eager to delve further into Golden Signals, I recommend exploring Google's SRE book via the provided link.

Nearly a year has passed since then, and I must confess that I did not secure that job at Delivery Hero. However, I am more than happy to have found my place at Gelato. With the guidance of brilliant engineering minds here, I had the opportunity to build my own micro service from the ground up and implemented the Golden Signals (a resounding 'yay' for that!).

The thrill of learning and implementing new concepts, particularly those that add value and save time for everyone involved, brings me immense joy. While I may have been late to the game in discovering and implementing these practices, I firmly believe that it's better to be late to the party than to never arrive at all.

Comments

Post a Comment

Popular posts from this blog

AI. Will it replace us or...?

AI!! The buzzword is too hot in the market nowadays. Do you have a technical product or an idea? If it doesn't have AI in it, then chances are it's not going to be sold like hot cakes. That is how things have changed lately. It is no wonder why me and my colleagues at Gelato want to see what AI can do in a niche department like customer support and service. And that is exactly what we did. For a company like Gelato, which is in the market for production-on-demand, there are a lot of customer questions you need to answer. It can be related to products, queries about shipping and pricing, and so on and so forth. Thus, our customer support team is always happy to help with these recurring questions. Let's take one example. A customer asked us, "Do you ship to Norway?" Now that is an easy question to answer if you have the knowledge written somewhere where you could refer to it and say, "Yes! As a matter of fact, we do." Following the same thread, the next q...
Post a Comment
Read more

Replication and transactional guarantee in MongoDB

One of the projects I am working on is using MongoDB as the database solution. And the project makes use of the nifty ORM mongoose to do the heavy lifting of data orchestration. It was high time I implemented transactions to the equation but because of a time crunch I was not able to start with one and the situation merely demands it at times. But come with an architectural change and the way the project was heading it was high time I implemented transactions by using MongoDB. According to MongoDB documentation, transactions are used when the situation requires, “atomicity of reads and writes to multiple documents (in single or multiple collections)”. MongoDB supports multi-document transactions. With distributed transactions, transactions can be used across multiple operations, collections, databases, documents, and shards. Now the piece of code to implement the same was pretty straightforward. // For a replica set, include the replica set name and a seedlist of the members in the URI...
Post a Comment
Read more