Wall climbing competition – Info

Build the backend app for the weekly climbing competitions in popular climbing resorts.


A couple of ski resorts would like to offer something special in the summer for the climbing community.  They have invested in these special bouldering walls,  both for kids and adults, which can track climbing times. 

Each wall has 2 paths you can follow, the easy path (green handles) and the hard path (red handles). These handles have pressure sensors in them. On the bottom side of the wall, there is a start button to start your climbing time and on the top there is a stop button to stop the time. 

Climbers can race each other on the wall. You either pick the green path, the red path or you use both coloured handles to get up there. 

The rules are simple: If you go for the red path, there is no time penalty for using the handles. Using the green handles will add 1 second per handle to your time. If you happen to use both colours, the red handles will also count for 1 second.  

Every week in high season, there is a price for the fastest climbers in the form of 2 free cocktails. There is also a wall of fame which has the 3 quickest climbers for each wall. 

Before climbers can participate, they need to register with their name and maybe also a nickname. When entering the competition areas, they will be given an RFID card. The unique id representend by this card needs to be linked to the registered climber. C.limbers need this card to register climb session times. When the RFID card is returned, the unique id is no longer coupled to the climber, so it can be reused again.

Use case 1: Registering a climb

You need to implement a solution so that climbers can register a climb session on a wall. Climbers each received a RFID keycard or a FOB. They need to scan this before they press the start button.

The result, which is the actual climb time with the penalty time added should be persisted. This result is what will be used for the scoreboards.

Additional information

The climbhandles fo the climbing wall have pressure sensors in them. These sensors are connected with a programmable unit which will record the unique id of the sensors (that is a UUID). This central unit will also record the unique climbing id from the RFID reader as well as the start time and the stop time. When the stop button is pressed, all of this information is send in a JSON packet using TCP. So you will need to implement a TCP server for this use case which is capable of receiving these packets. 

Use case 2: Get personal session times for a wall

Climbers want to be able to see their 10 best times for a specific wall, together with their last climbing time on that wall so that they can compare. 

Use case 3: Get the weekly scoreboard

Every week there is a new scoreboard, showing the fastest climbers for each wall. The climber that is the fastest on each wall, wins the week price of 2 free cocktails. 

You need to provide a solution for the app to be able to show the 3 fastest sessions times for each wall for this current week. 

Use case 4: Getting an RFID climb card

Before people can climb, they need an RFID card. The unique number of this card needs to be linked with the climber. This is required, otherwise we don’t know who climbed. Provide a way to do this. 

Use case 5: Register as a climber

If climbers want to participate to this competition, they need to register obviously! Provide a way for participants to register to the app. It is important to have a first nane, last nane and maybe a nickname. 


What are evolutions again? Evolution are extra challenges which you can complete after you have done the base challenges. Evolutions are exactly what you think they are: they are evolutions of the problem, changes in requirements of users and stakeholders. They are meant to test the design of your solution.

Evolution 1:

Climbers want to see more details

A lot of climbers are really into these challenges as they provide a awesome means of deliberate practice. They want to improve even on the slightest detail. So when climbers are looking at their own session times for a specific wall, they also want to know how many different climbing handles they have used. Implement this small change in your solution. 

Evolution 2:

New type of climbing wall

The climbing competiions are a real success. So the resorts want to expand the walls and bring it different challenges. They want to invest in a new type of wall. This wall doesn’t send a combined packet of a session. It sends events on the go. So when a climber presses the start button, an event is sent. Whenever a climber uses a handle, an event is sent. 

Extend the current solution so that type of wall can be used without a problem.