[emersion]

The database needs to be shared between multiple actors: several teams of multiple people working in different companies. For instance, a team may be working on a single project such as a new railway or a large timetable change. Another example would be multiple freight companies requesting new routes.

Additionally, the UI contains complicated elements such as custom maps with the railway network and custom graphs to visualize trains. There is a large ecosystem to implement this kind of stuff via Web technologies. A webapp also removes the need to distribute an installable binary on many different platforms (some may be quite restricted due to company policies) and many different machines (there are many users, see above).

Note that the system uses a client-server architecture but isn't really distributed.

[cbsmith]

> Note that the system uses a client-server architecture but isn't really distributed.

Yeah, I kind of agree. The thing is, it's orchestrating multiple containers to do the job. I can't figure out why you couldn't just have one container.

[emersion]

Part of the answer is that some of these services need to be scaled horizontally to be able to handle a significant number of users (e.g. tile servers, the core server), another part of the answer is architectural constraints (e.g. the core server needs to keep quite a bit of per-infrastructure data in RAM).

(Of course, it's completely possible to build a single container which runs all of the services in parallel, but then monitoring/scaling/availability/etc are more difficult to handle.)

[p_l]

Read the architectural description - it does mention why and how.