The source code for this post (both Part 1 and Part 2) is **available here** and you can **click here** to see my solutions for the other Advent of Code challenges.

Description for today’s challenge is here.

The input for Day 9 looks like this:

AlphaCentauri to Snowdin = 66

AlphaCentauri to Tambi = 28

AlphaCentauri to Faerun = 60

Snowdin to Tambi = 22

Snowdin to Faerun = 12

…

there are similarities between this challenge and Day 7 in that they’re essentially a graph problem. In that case, let’s model this problem as a graph:

in our model of this problem, we have a set of cities, and the connections between them (where the *key* is the city to travel *from*, and the *value* is a map of the cities that you can travel *to* and the *distance* between the pair).

Like we did in Day 7, let’s add a helper function to help connect two cities – a and b – together, along with the distance between them.

Armed with the above, we can now go back to our input, parse each line into two cities and their distance, and then *fold* over them to build up a graph:

notice that the information we get from the input list is actually bi-directional, which is why in the *fold* we have to add the direction from *a* to *b*, as well as from *b* to *a*.

Next, starting with each cities, we want to find the routes that’ll visit each city once and only once.

**aside:** *in hindsight, both the model and the path finding algorithm here can be simplified, I simply didn’t realise the distance data is bi-directional (it was implied through the example which I skimmed over and got started writing code…). For instance, the data is set up such that every city is connected to every other city, so the steps I have taken above to determine ‘which cities can I travel from here’ is redundant.*

*That said, I decided to keep the solution as it is because:*

*a) it can solve a more general problem where cities do not form a mesh network*

*b) it works, and pretty easy to understand, so why change *

The last building block we need to compose our final solution is the ability to calculate the total distance we have to travel in a route:

and to answer the challenge:

in hindsight, it might be better to write the above as:

* graph |> findPaths |> Seq.map calcDistance |> Seq.min*

## Part 2

To work out the longest distance one can travel, simply flap the last line to look for the max distance instead, simple:

**Yan Cui**

I’m an **AWS Serverless Hero** and the author of **Production-Ready Serverless**. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.

Further reading

Here is a complete list of all my posts on serverless and AWS Lambda. In the meantime, here are a few of my most popular blog posts.

- Lambda optimization tip – enable HTTP keep-alive
- You are thinking about serverless costs all wrong
- Many faced threats to Serverless security
- We can do better than percentile latencies
- I’m afraid you’re thinking about AWS Lambda cold starts all wrong
- Yubl’s road to Serverless
- AWS Lambda – should you have few monolithic functions or many single-purposed functions?
- AWS Lambda – compare coldstart time with different languages, memory and code sizes
- Guys, we’re doing pagination wrong