I've been working with Unity for a few years, and I've made a few multiplayer prototypes along the way. I wouldn't, however, call myself an expert in multiplayer programming by any means. The most complex project I've made was a locally hosted server where players could log in with a custom name and move around and chat with others (almost like a mini-MMO).

I've used Photon for all of my Unity networking endeavors, but are there were any alternatives or other frameworks available that would suffice or surpass Photon in features/usability? Building off that, what rules and decisions go into the architecture of multiplayer games? In a general sense, what design choices need to be made about what server and client-side functions should be?

The only other multiplayer library I've used in Unity was a custom client library we wrote on our own, so I can't help on that front.

However, when deciding on networking, the first and most important decision, is what kind of gameplay you want to support! Turn-based, extrapolated-state-snapshots, and input-synchronous-deterministic are the three main options, and they're good at different things.

The second decision is who owns the “state” of objects. “Obviously, it's the server” is the safe default, but for various gaming cases, certain facets of certain objects being owned by the players might be just fine, and help break certain logjams.

Then you can start looking for a library that either supports the model you want to use, OR which at least has the features you need to implement the model you want, on top. Depending on which library you choose, you may get things like “property declaration” and “RPC mechanisms” built-in, or you may have to carefully design those (the “domain specific language” you use to talk about networking, in a sense,) yourself.

Only after all this, does it matter to start thinking about what kind of hosting you'll want, what kind of databases to use, how to integrate web/mobile/in-client sign-up/sign-in, and so forth. Those are actually the “simple” bits, or at least “lower risk.”