How to Make a Technical Selection?

There are so many tradeoffs, how to carry on?

Last week, an engineer asked me how to make a technical selection. And he provided a real-world example. Their organization wanted to implement an event-driven architecture, and there were three options available right now — MQTT, AMQP, and Kafka — but he didn’t know how to make a decision.

My answer, as always, was “it depends”.

“Everything in software architecture is a tradeoff”. — Mark Richards

Because of the tradeoffs, there will never be a standard answer, in other words, there will never be a silver bullet.

However, we always have to make a decision, what are the tradeoffs? At that moment, I turned back to him and asked.

• Do you understand your requirements completely?
• Do you know what these three techniques are exactly doing?

Take message queues as an example, I have written an article previously on what use cases to consider when choosing a message queue.

• Propagation: Can fan-out be supported?
• Delivery: What kind of delivery guarantee does it have? At least once or exactly once?
• Persistence: Can messages be persisted?
• Consumer group: Does the receiver scale horizontally?

These are the generic requirements for a message queue, and even if you don’t choose a message queue, listing the generic requirements for a technical stack can more or less filter out some options.

Then, after filtering by generic requirements, further filtering could be done based on the specific use cases. For instance.

• Is there a large volume of messages to be written?
• Is there a limit to the bandwidth that can be transferred?
• What kind of security is required?
• What programming languages are expected to be integrated?

To answer questions such as these, in addition to a precise understanding of the requirements, we must also have a clear understanding of the technical stack candidates.

Therefore, architects use a similar thought process when making a technical selection to clarify requirements and learn about the technical stack, and finally make a decision. The decision is not about choosing the latest technique, or just playing around with it as if it works.

Nevertheless, we will always encounter the situation that all needs are well met, after all, nowadays technology is developing rapidly, and many of our needs have already been implemented, so what should we do? Throw the dice?

Wait, you can ask more questions.

• Should we maintain this technical stack ourselves or purchase a managed service?
• Is there a budget limit?
• How do we monitor it, whether we operate it ourselves or buy a managed service?
• Do we have any experience in using it?

When there is no more question to ask to filter, then the last thing to do is to choose what we love and love what we choose, and not to waver from one option to another.

Any technical stack from finalization to production environment must go through time, experience and learning in the process of use. If we change our choices easily, it’s hard to become an expert.

Originally published on Medium