How Does Your Navigation App Pick a Route? The Maths Behind the Waze Debate

Navigation apps have been in the Malaysian news all week. Under a circular dated 20 October 2026 from the Chief Secretary to the Government, civil servants have been barred from using Waze, following a decision of the National Cybersecurity Committee, which cited data security concerns over the app’s Israeli links. Waze was founded in Israel and has been owned by Google since 2013. On 23 October, Prime Minister Anwar Ibrahim said the government could consider discontinuing Waze altogether if local apps prove good enough, and urged the public to try TuJu, developed for the Malaysian Highway Authority (LLM) with the Prosignal Consortium. The public has not been barred from Waze, and Google Maps is unaffected.

Whichever app ends up on your phone, they all face the same problem, and it’s a lovely piece of mathematics. You type in a destination, and a second later the app has picked one route out of a staggering number of possibilities. How?

Start with how many routes there are. Picture a simple grid of streets, ten blocks across and ten blocks up, and you want to get from one corner to the opposite one without ever doubling back. Every route is some arrangement of 10 moves right and 10 moves up, and the number of ways to arrange them is 184,756. Make the grid twenty blocks each way and it jumps to about 138 billion. A real city is not a neat grid, and a trip across the Klang Valley passes through far more than twenty junctions, so checking every possible route one by one is out of the question, even for a fast computer.

The trick that solves it is called Dijkstra’s algorithm, after the Dutch computer scientist Edsger Dijkstra, who worked it out in 1956. He later said he designed it in about twenty minutes, sitting at a café in Amsterdam, without pencil or paper. The idea is simple enough to do in your head, so let’s do it.

Here is a small map. You are at Home and want to reach the Office. Between them are three junctions, which we’ll call B, C and D. The roads, with travel times, are: Home to B, 5 minutes. Home to C, 2 minutes. C to B, 1 minute. B to D, 4 minutes. C to D, 7 minutes. D to Office, 3 minutes. And B to Office, 9 minutes.

Dijkstra’s rule is: always deal next with the closest junction you haven’t finished with. From Home, you can reach B in 5 and C in 2. C is closer, so you settle C at 2 minutes. Now look onward from C. Going through C, B is 2 + 1 = 3 minutes, which beats the 5 you had, so B becomes 3. D through C would be 2 + 7 = 9. The closest unfinished junction is now B, at 3, so you settle it. From B, D is 3 + 4 = 7, which beats 9, and the Office is 3 + 9 = 12. Next closest is D, at 7. From D, the Office is 7 + 3 = 10, which beats 12. The Office is settled at 10 minutes, by the route Home, C, B, D, Office.

Notice two things. First, the road that looks most direct, Home straight to B, isn’t on the winning route. The detour through C is faster, which is exactly the kind of route a navigation app finds and a driver going by instinct misses. Second, we never listed every route. Each step only compared a handful of small sums, and anything that was already slower than a known option was dropped. That’s why the method scales from five junctions to millions.

Real apps add a refinement that’s pure estimation. Instead of spreading out evenly in every direction, they lean towards the destination by adding a rough guess of the time remaining, based on the straight-line distance. A junction 2 kilometres the wrong way gets checked later than one 2 kilometres the right way. The guess doesn’t have to be exact, only sensible. In other words, it’s congak: a quick estimate that keeps the precise calculation pointed in the right direction.

The maths is the easy part, though. The numbers on every road in our map were fixed, but on a real road at 6pm they change by the minute. An app is only as good as its picture of the traffic right now, which comes from reports and speed data from the people using it. That is why user complaints about new apps tend to focus on accuracy and missing real-time incident data rather than on the route-finding itself. Dijkstra’s idea is free for anyone to use. Knowing the current travel time on every road is the hard part.

Next time an app sends you on what looks like a strange detour, try a bit of congak on it: add up the minutes it expects for each part and compare them with the obvious road. Breaking a problem into small sums is a skill you can practise in a couple of minutes a day at cerdikcerdik.com/math. And if you enjoy the step-by-step ruling-out in Dijkstra’s method, the same kind of thinking is the heart of Sudoku at cerdikcerdik.com/games/sudoku.