Tapping into event-driven design can be daunting, even for experienced software programmers. We have a tendency to get intimidated by a lot of complex concepts involving the usage of an event bus like Kafka, and our focus starts off trying to understand how to maintain such a complex distributed network. In this post I will try to tackle a simple*(ish)* use case where I will provide some hints on how to tap into an already existing event bus architecture network.

There are many things which keep us developers shrieking and hiding behind oak doors. Be it Bugs, Incidents, KPIs, Javascript, YAFF (Yet another Frontend Framework), Game of Thrones spoilers — the mention of these is enough to send cold chills down our spines. But nothing compares to the agony of going through tedious and lengthy procedures to crack a job interview.

I will try to generalise the process, give some tips on how to handle different areas (more focussed on the tech aspect of course). Before we begin, please note that in no way what I speak about in this article can be considered a good way to crack an interview or is applicable to all jobs in Germany. These are simply ramblings of a mere software developer, observing his ecosystem in the last 9 years, and I have not really conducted a thorough research on this.

I came across this interesting use case when I was trying to unmarshall some JSON into case classes and I wanted to take into account missing properties or keys. Since I have been using Golang prior to using Scala, this was quite natural in Golang as it automatically took care of missing properties. Let’s dive into the following example to find out what exactly I am talking about.

Consider the case class:

When I started learning Go, a couple of its features had really drawn me towards it. The first was the ease in which pointers could be used. The second was the ease with which its asynchronous capabilities could be used. In this blog, I would try to use the different ways you can solve a very simple problem.

Let us take a very common example where we would simply try to build a program which would check if a set of websites/urls are up and running or not. For this example, I have picked 5 airline websites.

I turned into a Gopher about 10 months ago and have never looked back. Like many other gophers, I quickly found the simple features of the language quite useful to quickly build fast and scalable software. When I was initially picking up Go, I was playing around with different multiplexers available to be used as an API server.

If you are coming from a Rails background like me, you probably would also have struggled in building all the features which one can get from Web Frameworks. Coming back to the multiplexers, I found 3 to be quite useful: Gorilla mux, httprouter and bone (ordered in ascending order of their performance). Even though bone had the best performance and a simpler handler signature, it was not mature enough to be used in a production environment yet. So I ended up using httprouter.