I used to play a high level cleric a while back in an MMORPG game called EverQuest. As with most high level characters, I was in a raiding guild. For those who didn’t know what a raid is like, basically, you get together with other players (usually in the same guild), usually around 20+ players with different skill sets and you work together to kill high level NPCs that required a whole lot of different tactics and cooperation between the raid members.
One aspect of this game that fascinates me is the tactics / strategies that are required for the raid to be a successful raid (minimal casualties and goal reached / NPC killed).
For example, as a cleric one of my main task is to keep our main tank alive (a tank is a primary punching bag for the NPC mob). If you miss casting your healing spell because you’re out of mana (magic energy) or you didn’t use the right healing spell (takes too long or doesn’t have enough healing power), your tank will most likely will dead in no time and most likely everyone else in the raid will die as well.
Amazingly, the system work in the smaller scale (2 to 6 people group) as well as in larger scale (20+ people raid). However, at a larger scale (raid), you need to adjust your tactic. For example, a single cleric will not be sufficient to heal the main tank by his / herself, due to healing spell speed, maximum mana constraint, etc. So you need to have a cleric chain / queue, in which 2 or more clerics take turns healing the main tank in turn. Sometimes you also need to have spot healers (with quick, casting time wise, healing spells ready) just in case the main tank is suffering too much damage. Here you can see, similarly in software architecture, depending on the software, you will need different scaling strategy between small scale system and large highly scalable system. In a web application, you can think of this as a web farm / cluster sort of thing.
Even this sometimes is not enough due to the constraint of maximum mana pool per cleric. In this case, the game have other specialized classes like mage who can create a mana injector rod and necromancer who can regenerate mana faster than any other classes at the expense of their own health and transfer them to whoever they wish / need it. So you can see here that the cleric chain is being served by additional chain of mages and necromancers (to supply them with mana so they can continue healing the main tank). Here, you can make a connection to one layer of service is depending on a lower level service to feed them data / information, sort of like tier / layer separation.
Sometimes the raid will require redundancy just in case. For example, the raid leader will nominate a primary tank (the one that is getting hit the most by the NPC mob) and also a secondary tank just in case the primary tank goes down / die. Can you say active / passive cluster failover?
Communication can be served in different channels. For example, the raid clerics will have their own channel so they can communicate effectively. I.e. Notified the rest of the cleric chain that they are out of the rotation due to out of mana quickly before their turn to heal so the next cleric in chain can take up the responsibility. Or to notify the next cleric that his / her turn is up next. A different channel is being used to announce to the other support classes like necromancer that a particular cleric is in need of rapid mana transfer. Or a one to one / many mapping between a particular cleric with his / her own support staffs (mage / necromancer) can be established when needed as well. You can easily make a similar analogy to this in software architecture… let say… Enterprise Service Bus / Publish Subcribe mechanism where each cleric in the chain subscribe (join) to a particular communication channel and they can publish (send their message / notification) to that channel so other clerics / interested party can react to it in whatever manner they deem necessary.
Execution order is also part of the strategy. For example, the main tank will start hitting the NPC mob, and then when he is down to 50% of his health, the first cleric in the chain start healing. This is kind of similar to that of an SLA in software / service architecture, where a certain service level agreement is establish that the tank should never fall below 30% of his / her health (which depends on the mob that is being raid) and for him / her to not fall below that number, the cleric should start healing when they can monitor that the tank is at 50% of his health.
Just food for thought… Isn’t that fun? Hehehe.