Tech Selection: The Architect’s Soul‑Searching Moment and How to Choose Wisely

Why technology selection matters

Choosing the right technology can determine a project's success, while a wrong choice may incur large refactoring costs.

Typical selection scenarios

Language/Framework : Java vs Go vs Python – impacts development efficiency and team capability.

Database : MySQL vs PostgreSQL vs MongoDB – impacts data storage and query capabilities.

Cache : Redis vs Memcached – impacts performance and feature set.

Message Queue : Kafka vs RabbitMQ vs RocketMQ – impacts throughput and reliability.

Search : Elasticsearch vs Solr – impacts search capability.

Cloud Service : AWS vs Alibaba Cloud vs self‑hosted – impacts cost and operations.

Selection failure example

Case: An e‑commerce company chose MongoDB for order storage.
Problem: Orders require strong consistency, which MongoDB does not provide.
Result:
- 3 months spent migrating to MySQL
- Business stalled during migration
- Team morale dropped
Lesson: Technology selection must consider business characteristics.

Selection methodology

1. Clarify requirements

Functional (Must‑Have)

Features that must be supported

Constraints that must be met

Non‑functional (Should‑Have)

Performance requirements

Availability requirements

Scalability requirements

Optional (Nice‑to‑Have)

Additional features

Optimization characteristics

2. List candidate options

Gather all possible solutions for the scenario.

3. Define evaluation criteria

Feature match – does it satisfy functional needs? (30%)

Performance – meets performance targets? (20%)

Stability – maturity and community activity? (15%)

Learning cost – team learning curve? (10%)

Operations cost – maintenance difficulty? (10%)

Cost – license and cloud fees? (10%)

Risk – vendor lock‑in or technical risk? (5%)

4. Evaluate and compare

Score each option against the criteria and compute a weighted total.

Database scoring example :

Feature match – MySQL: 4, PostgreSQL: 4, MongoDB: 3

Performance – MySQL: 4, PostgreSQL: 3, MongoDB: 4

Stability – MySQL: 5, PostgreSQL: 4, MongoDB: 4

Learning cost – MySQL: 5, PostgreSQL: 3, MongoDB: 4

Operations cost – MySQL: 4, PostgreSQL: 3, MongoDB: 3

Cost – MySQL: 5, PostgreSQL: 5, MongoDB: 3

Risk – MySQL: 5, PostgreSQL: 4, MongoDB: 3

Weighted score – MySQL: 4.45 , PostgreSQL: 3.65 , MongoDB: 3.45

Cache comparison

Data structure : Redis supports String/Hash/List/Set; Memcached supports String only.

Persistence : Redis supports persistence; Memcached does not.

Cluster mode : Redis offers native cluster; Memcached lacks native clustering.

Performance : Redis is slightly slower than Memcached.

Use case : Redis for complex data and persistence; Memcached for simple caching.

Message queue comparison

Throughput : Kafka – very high; RabbitMQ – high; RocketMQ – high.

Latency : All three provide low latency.

Feature set : Kafka – basic; RabbitMQ – rich; RocketMQ – rich.

Ordered messages : Supported by all.

Transactional messages : Supported by RabbitMQ and RocketMQ, not by Kafka.

Delayed messages : Supported by RabbitMQ and RocketMQ, not by Kafka.

Typical scenarios : Kafka – big data / logs; RabbitMQ – mid‑size systems; RocketMQ – e‑commerce, finance.

Programming language comparison

Java : Advantages – mature ecosystem, abundant talent; Disadvantages – verbose syntax; Suitable for enterprise applications.

Go : Advantages – high concurrency, concise; Disadvantages – weak generics; Suitable for cloud‑native, microservices.

Python : Advantages – fast development, AI‑friendly; Disadvantages – poor performance; Suitable for scripting, AI, data processing.

Rust : Advantages – performance, safety; Disadvantages – steep learning curve; Suitable for system programming.

Common pitfalls

Chasing hype – new technology may be immature and risky.

Over‑analysis – excessive research delays decisions.

Political selection – following vendor trends instead of real needs.

Perfectionism – seeking a flawless solution that rarely exists.

Avoidance guidelines

Demand‑driven: ask whether the technology solves the problem, not whether it is popular.

Team fit: choose what the team can handle, not the flashiest option.

Incremental evolution: start with a sufficient solution and evolve later.

Cost awareness: pick the option with the lowest total cost, not necessarily the free one.

Decision principles

Functional match outweighs novelty.

Prefer mature, proven technologies with active communities.

Avoid vendor lock‑in; keep migration paths open.

Choose a solution that is "good enough" rather than perfect.

Decision record example (ADR)

# ADR-XXX: Choose Redis as the caching solution
## Status
Approved, 2024-01-15
## Background
System needs caching to improve performance.
## Candidate Options
1. Redis
2. Memcached
3. Local in‑process cache
## Evaluation Criteria
- Feature match
- Performance
- Stability
- Operations cost
## Decision
Select Redis
## Rationale
1. Rich data structures
2. Active community, good docs
3. Team has Redis experience
4. Supports persistence and clustering
## Risks
- Increased ops complexity (accepted)
- Learning cost (already known)
## Related Decisions
- ADR-YYY: Cache expiration strategy

Step‑by‑step selection process

┌─────────────┐
│ 1. Clarify requirements │ ← What must be satisfied?
└──────┬──────┘
       ↓
┌──────▼──────┐
│ 2. List options │ ← What candidate solutions exist?
└──────┬──────┘
       ↓
┌──────▼──────┐
│ 3. Define criteria │ ← How to evaluate?
└──────┬──────┘
       ↓
┌──────▼──────┐
│ 4. Evaluate & compare │ ← Score each dimension
└──────┬──────┘
       ↓
┌──────▼──────┐
│ 5. Make decision │ ← Comprehensive judgment
└──────┬──────┘
       ↓
┌──────▼──────┐
│ 6. Validate test │ ← Small‑scale verification
└─────────────┘

Key takeaways

Define functional, non‑functional, and optional requirements before evaluating options.

List all candidate technologies and assign weighted evaluation dimensions.

Score each candidate, compute weighted totals, and record the rationale.

Avoid common traps such as hype chasing, over‑analysis, political pressure, and perfectionism.

Follow the principles of requirement satisfaction, conservatism, replaceability, and sufficiency to ensure the chosen technology fits the problem and the team.