Application Architectures - The Practice of Cloud System Administration - page 89

Imagine how difficult creating this functionality would have been without a message
bus. The control panel machines would need an “always up-to-date” list of all the redirect
servers.Itwouldhavetohandledownmachines,newmachines,andsoon.Thecommunic-
ationwouldnotbeoptimizedforthenetworktopology.Itwouldbeverydifficulttoachieve
the same quality of service as that provided by message bus.
Without a message bus system, adding a new service would mean changing all the data
providers to also send a copy to it. Suppose an entirely new mechanism for calculating
trending links was devised. Without a message bus, the redirect servers would have to be
updated to send information to them. With the message bus system, the new trend serv-
er could be added and run in parallel without requiring changes to the other servers. If it
proved successful, the old trend server could be disconnected just as easily.
4.6.4 Example 2: Employee Human Resources Data Updates
An enterprise had a large employee base. Each day many new employees were hired, left
the company, changed names, or changed other database attributes. Meanwhile, there were
numerous consumers of this information: the login/authentication system, the payroll sys-
tem, the door-lock systems, and many others.
In the first incarnation of the system, a single database was maintained. All systems
queried the database for changes. As the company grew, however, the database got more
and more overloaded.
In the second incarnation, any department that needed to be informed of user change
requests had to write a plug-in that would be called for each change. The plug-in had to
handle subcommands including add, update, remove, name-change, and others. The plug-
insallranunderthesameroleaccount,whichmeantthisoneaccounthadprivilegedaccess
toeverycriticalsysteminthecompany.Itwasanightmare.Ifonedepartment'splug-inhad
a bug, it would take down the entire system. This system remained in operation for years
even though it was very brittle and required a lot of work to keep it running.
The newest version of the system implemented a message bus. All changes went
through one system that was the publisher on a channel called “user updates.” Any depart-
ment that needed to be informed of changes would subscribe to that channel. The depart-
ment could run its system on its own role account, which isolated each department into its
own security domain. Each department also had its own failure domain, as the failure of
one listener did not affect any of the others. A synchronization mechanism talked to each
department once a day so that any missed updates could be processed.
New departments could join the system at will without affecting any others. Best of all,
this system was very easy to maintain. Responsibility was distributed to each department.
The main group simply had to make sure the publisher was working.