A Chapter's Briefs of FoSA: Analyzing Trade-Offs

FoSA: Fundamental of Software Architecture.

Thinking like an architect is about seeing trade-offs in every solution. However, software developers tend to see benefits in every solution. If a developer want to level-up their play field, they should starts to see the negatives of their solutions.

---

Architecture is the stuffs you can't Google
— Mark

Which is why the famous answer to architecture question in the universe is "it depends" – many annoyed, but it's unfortunately true.

It depends on the deployment environment, business drivers, company cultures, budgets, timeframes, developer skill set, and dozen other factors.
— FoSA, Page 42

Examples

The chapter give us an example of item auction system which have Bid Producer and three consumers: Bid Capture, Bid Tracking, and Bid Analytics. The communication could be done using queues in point-to-point messaging fashion or by using a topic in pub-sub messaging fashion.

The illustrated messaging options shown in Figure 1-1 and Figure 1-2 below.

Clear Advantages

The clear advantage and obvious to this problem in Figure 1-1 is architectural extensibility. Unlike the Figure 1-2, where the Bid Producer needs to connect to three different queues.

In a scenario of adding new service. In Figure 1-1, it doesn't need any changes in Bid Producer, the new service can up and subscribe into the topic. On the other hand, using Figure 1-2 require us to modify Bid Producer to add an additional connection to the new queue.

With this analysis, it seems clear that the topic approach using pub-sub messaging model is the obvious and best choice. However, Rich Hickey, the creator of the Clojure programming language said:

Programmers know the benefits of everything and the trade-offs of nothing. Architects need to understand both.

Trade-Offs

Notice in Figure 1-1, with a topic, anyone can access bidding data, which introduce a possible issue with data access and data security. In illustrated queue model, Figure 1-2, the data sent to the queue can only be accessed by specific consumer receiving that message. If a rogue service did listen in on a queue, those bids would not be received by the corresponding service, and a notification would immediately be sent about the loss of data.

In other words, it's very easy to wiretap topic, but not a queue.

Other Factors

In Figure 1-1, the topic solution only supports homogeneous contracts. All services that receives the bidding data must accept the same contract and set of bidding data. In Figure 1-2, the queue solution can make each services have its own contract specific to the data it needs.

For example, Bid History service requires the current asking price with the bid, but no other services need that information. In topic, this will impact all services that subscribe the topic. In queue, it will not impact other services and modified contract only required to that one service.

Another disadvantage of the topic in Figure 1-1 is that it does not support monitoring of the number of messages in the topic and hence auto-scaling capabilities.

However, in queue, each queues can be monitored individually, and programmatic load balancing applied to each bidding consumer so that each can be automatically scaled independently from one another.

Figure 1-3 summarize the topic's trade-offs.

Summary

Now which is the better option? It still: depends!

This chapter strongly emphasize the important of seeing trade-offs, and regarding above examples, we should then asking, "which is more important: extensibility or security?"

That decision will always depends on business drivers, environment, and a host of other factors which explained in other next sub-chapters.