From The Challenges - Load Balancer

In this Coding Challenges newsletter I’m sharing some of the common mistakes I see software engineers make when tackling the Coding Challenges.

I’m sharing the mistakes people make and some thoughts on how you can you avoid making the same mistakes when taking on the coding challenges or when writing software professionally.

News: CodeCrafters Add Kafka

I’ve been asked to add a Kafka Coding Challenge for a while, but haven’t had chance yet. For those of you who are interested codecrafters.io now has a build your own Kakfa challenge.

If you’re interested in codecrafters.io you can get 40% off as a Coding Challenges reader and it helps support Coding Challenges.

Recapping The Load Balancer Coding Challenge

In the build your load balancer coding challenge the goal was to build your own application layer load balancer.

The goals for the load balancer coding challenge are to:

• Build a load balancer that can send traffic to two or more servers.
• Health check the servers.
• Handle a server going offline (failing a health check).
• Handle a server coming back online (passing a health check).

Five Common Mistakes Software Engineers Make Solving The Load Balancer Coding Challenge

I’ve pulled together this list of common mistakes from the hundreds of submissions I’ve been sent privately and the many shared in the Coding Challenges Shared Solutions GitHub Repo.

Mistake 1 - If You Have Shared Mutable State, Protect It

If you have mutable state shared that is written to by different threads of execution there is potential for a race condition. The simplest way to avoid this is to protect with some form of synchronisation primitive offered by your programming language.

Mistake 2 - Using A Library

The fun and interesting part of this coding challenge is learning to handle TCP, reading and writing to sockets and building servers. Using a library that provides 95% of the functionality cheats you out of that learning.

For production code, do please leverage the appropriate libraries. As a learning experience you’ll get more out of the Load Balancer coding challenge by building the server and TCP handling yourself.

Would a programming language agnostic course on building network clients and servers be interesting and useful? If so reply to this email or add a comment and let me know!

Mistake 3 - No Logging

A load balancer is part of a distributed system and one of the simplest ways to debug a distributed systems is to review the logs. For that reason it’s always a good ideas to add logging to any server you build and the logs should always include a timestamp.

Mistake 4 - Not Handling Errors

I know it’s easy to skip error handling when building a side project or working through a tutorial, but try to resist. For the load balancer, consider what happens if a request is malformed or a server/network connection fails part-way through a request.

Mistake 5 - Not Providing A Script To Launch The Tool

It’s awesome seeing the wide range of technology stacks and programming languages used to solve the coding challenges.

But there’s a downside, if the stack doesn’t produce a binary it feels unfinished if the instructions to run it tell you to run it using node, python or ruby. It feels even worse if the instructions reference go run or cargo run. Part of building real-world solutions is finishing and building a distributable / deployable artefact.