Every technical decision has a context, cost and criteria. When someone asks 'Which should I use?', this catalog offers a comparison to help them decide.
"Doing something the way it has always been done does not make it right, or the best choice."
Cesar Zanis
When to use
An immediate response is needed. Simple CRUD. Low to moderate volume. Public APIs consumed by browsers.
When NOT to use
Long-running operations (>2 s). Fan-out to multiple consumers. Eventual consistency is acceptable.
Trade-off Cost
Temporal coupling: a destination failure affects the caller.
When to use
Long operations. Independent teams. Automatic retries. Absorbing traffic peaks.
When NOT to use
The caller needs an immediate answer, such as login, validation or checkout.
Trade-off Cost
Additional initial complexity: dead-letter handling, queue monitoring and idempotency. The benefit is improved resilience.
When to use
Frequent internal service communication. Strongly typed contracts. Bidirectional streaming.
When NOT to use
Public browser APIs requiring native support. Teams unfamiliar with protobuf.
Trade-off Cost
A learning curve and schema-management work, in exchange for efficient binary contracts and lower overhead.
When to use
High-frequency endpoints. Complex joins. Tight latency requirements. Control over execution plans.
When NOT to use
Simple administrative CRUD. Prototypes where delivery speed matters most.
Trade-off Cost
More manual mapping code, in exchange for explicit queries and more predictable SQL behavior.
When to use
Low-volume backoffice CRUD. Prototypes. Teams with limited SQL experience.
When NOT to use
Mobile synchronization, heavy reports or endpoints with tight latency requirements, unless the generated queries are validated.
Trade-off Cost
Convenience, with a risk of inefficient generated queries under production load.
When to use
Transactional tables, public APIs and a need to separate internal identifiers from public identifiers.
When NOT to use
Small lookup tables where an extra public identifier is unnecessary.
Trade-off Cost
One extra column and a UNIQUE index. Public identifiers still require proper authorization checks.
When to use
Distributed identifier generation. Time-ordered UUID v7. Identifiers generated on the client.
When NOT to use
Random UUIDs on write-heavy clustered indexes without measuring fragmentation and storage cost.
Trade-off Cost
One identifier column. Evaluate index size, locality and the database engine's storage behavior.
When to use
Business history, reversible deletion and audit requirements, subject to a defined retention policy.
When NOT to use
Temporary or ephemeral data with no business history requirement, or data that must be erased.
Trade-off Cost
An additional column and a mandatory filter on relevant reads. Retention and erasure still need explicit handling.
When to use
Sessions, tokens, real-time counters and shared data. Define TTLs, memory limits and eviction policies.
When NOT to use
Large binary files or data that is better served from object storage or a CDN. Evaluate payload size and access frequency.
Trade-off Cost
Memory and operational costs. Verify that the latency benefit justifies them.
When to use
Static assets. Immutable versioned API responses. Images. Non-personalized pages.
When NOT to use
User-specific or real-time data without an appropriate private-cache or invalidation strategy.
Trade-off Cost
Usually inexpensive. Invalidation is the main challenge: use ETags or versioned URLs.
When to use
Data changes on each request, inconsistency is costly, or queries are already fast enough.
When NOT to use
Expensive queries that return the same result for several minutes.
Trade-off Cost
Less cache complexity, in exchange for database load and request latency.
When to use
Small systems with few dependencies, a well-understood domain and documented migration costs.
When NOT to use
Production systems with many consumers, undocumented business rules or a poorly understood domain.
Trade-off Cost
A high risk of losing implicit business rules. Requires an explicit, documented decision.
When to use
Active production systems, incremental migration with rollback, and teams that must keep delivering.
When NOT to use
Trivial systems without consumers where the migration machinery adds little value.
Trade-off Cost
More migration infrastructure and coordination. It can reduce disruption, but does not eliminate downtime risk.
When to use
Supported frameworks, productive teams and migration costs that exceed the clear benefit.
When NOT to use
Unsupported frameworks, poor team productivity and technical debt growing faster than delivery.
Trade-off Cost
Lower immediate cost. Requires regular reviews so debt does not accumulate unnoticed.
When to use
Boilerplate, CRUD, tests and code following an established project pattern.
When NOT to use
Critical business algorithms that nobody on the team can review confidently.
Trade-off Cost
Potential delivery gains, provided the output is reviewed and tested. Unreviewed code introduces production risk.
When to use
Exploring alternatives, drafting ADRs, analyzing trade-offs and reviewing proposals.
When NOT to use
Delegating the final decision. AI proposes; people remain accountable.
Trade-off Cost
A wider set of perspectives, limited by the organizational and historical context you provide.
When to use
Sensitive code, logs or personal data that must remain within approved infrastructure, with appropriate local controls.
When NOT to use
Tasks beyond the local model's capability. Evaluate a permitted cloud service if it meets the data policy.
Trade-off Cost
Local control does not guarantee security. Account for access, telemetry, updates, hardware and model quality.
If you cannot explain when NOT to use an approach, you do not yet understand its trade-offs. Understanding the cost is part of the decision.
Czanix Tech ReferenceNeed help evaluating a trade-off in your own context?
Talk to Cesar Zanis
