⚒Every Architectural decision comes with trade-offs. There is no right or wrong.
👷♂️ Software Architect Series — Part 2.
A business problem can be solved in many ways but choosing the most effective solution depends upon many factors and the preference of a solution will usually differ from client to client. Think of it in this way:
In the city Z, there is an intra-city commute problem and to solve this, Person A wants to start a bus service network across the city, however, due to constrained budget initially, he choses to deploy non-AC buses in his initial fleet. On the other hand, his competitor Person B has got some funds in his backing. He decides to deploy both AC/Non-AC buses in his initial fleet.
On the first instance, it might seem that person B has got added advantage with better customer experience (providing air conditioned buses); however, person A can still beat the competition with competitive ticket prices and shorter route selection between source and destination. There would be other factors which will govern success of their business endeavor.
Similarly, in Software domain, there is no definitive answer to judge which solution is better. One can not just simply dictate, use microservices as they are better or use RPC over REST, as they are faster. The answer depends on respective trade-offs, business drivers, timeframe to complete the project, available skill set, etc.
Let us take another example:
In an order management system, when a customer places an order, the Order Producer service generates the order details and sends that information to various other services involved in order processing. These services could include Order Processing, Inventory Management, Payment Processing, and Order Fulfilment.
The architect might consider using either queues in a point-to-point messaging fashion or a topic in a publish-and-subscribe messaging fashion to handle communication between these services. However, the correct answer depends on various factors.
Let us analyze:
If architect decides to use Topics, he gets a fair advantage of system extensibility. Order Producer service is only connected to a Topic and topic sends generated orders to respective services. If a new service wants to subscribe the order generation, it is quite easy. On the contrary, if he choses to use queue system, then a new queue needs to be employed and Order Producer needs to be modified to accommodate this request. Clearly, Topic seems to be winning by a fair hand. However, let us hold our horses for a bit.
Let us analyze downside of using topics: Data is easily accessible, possible leading to data access and security issues. And this is where queues will fare better. Data sent over queues can only be accessed by intended consumer receiving the message and in case of breach, it is easy to capture.
👉 Hence, the point is, to decide which solution is better, in this case “Extensibility vs Security”; a Software Architect must carefully investigate business drivers, timelines, environment and numerous other possible factors. Google or GPT will not help you, neither system design crash courses. An architect gets better with experience.
📕 Meanwhile, if you are a young developer and interesting in building thought process to develop enterprise application, do check out my book: “Objects, Data & AI”, which has been out recently. Book can be accessed at the link below:
https://objects-data-ai.github.io/
This book is available at Google Books as well and print copy can be ordered from Notion Press.
Contact me, for specific details.