DEV Community: meet

Decision Matrix To Navigate Technology Choices

meet — Wed, 27 Aug 2025 09:48:11 +0000

Decision matrix that can be used for various types of engineering decisions:

Factor	Description	Questions to Ask	Examples
Business Requirements	Aligns with product goals, timelines, and scope.	- Does this choice solve the business problem effectively? - Is this feature going to add measurable value to users or the product? - What are the KPIs for success?	- New feature with clear business impact - Critical bug fix required for customer satisfaction
Technical Complexity	How complex is the solution, both in terms of development and maintenance?	- How difficult is it to implement? - Are there any unknowns or potential risks in this design/solution? - Will it require a lot of time or effort to maintain?	- Implementing a new caching layer - Integrating with a third-party service or API
Performance	How well does the solution perform in terms of latency, throughput, load handling, and scalability?	- Does this solution meet our current and projected load needs? - Can we handle future growth in traffic/data? - Does it align with SLAs for performance (e.g., latency requirements)?	- Handling thousands of concurrent users - Real-time data processing with low latency
Scalability	Ability to handle increased load over time. Does the system scale horizontally and vertically? Does it have limits for future growth?	- How does the system handle an increase in users/data? - Will it scale effortlessly or require significant changes as we grow? - Can we partition data or handle increased traffic easily?	- Migrating to a microservices architecture - Transitioning from monolith to cloud-native
Maintainability	How easy is it to maintain, debug, and monitor the system after deployment? Does the system require heavy monitoring or does it provide clear diagnostics?	- How easy is it to test and debug this feature/system? - Can developers quickly understand and work with the system? - What is the learning curve for new engineers?	- Choosing a simple, well-documented framework - Legacy code that needs modernization
Reliability & Fault Tolerance	Ensures the system has resilience and can recover from failure.	- Does this solution provide high availability and fault tolerance? - Are there failover mechanisms in place? - What is the disaster recovery plan? - Does it meet the availability SLA?	- Using a distributed database with replication - Redundant services to ensure uptime
Security	How secure is the solution? Does it follow best practices for authentication, authorization, data protection, and access control?	- Does the solution meet security compliance requirements? - Are there any known vulnerabilities or risks? - How does the system handle encryption and access control?	- Using OAuth 2.0 for user authentication - Encrypting sensitive data at rest and in transit
Development Speed	Time required to implement the solution. Does the solution fit within the desired release timelines?	- How quickly can this solution be developed and delivered? - Does it meet the deadline or sprint goals? - Is there enough time for testing and QA before release?	- Using existing libraries or frameworks for rapid prototyping - Fast MVP development using microservices
Team Expertise	Does the team have sufficient expertise with the technology? What is the learning curve?	- Do we have developers who are experienced with this technology? - Will the team need additional training or ramp-up time? - Is this technology well-supported in the community?	- Using Node.js when the team is familiar with JavaScript - Selecting a database technology your team has experience with
Cost & Resources	Financial costs, infrastructure costs, and resources (personnel, tools) required to implement the solution.	- Does this solution fit within the budget? - Are there hidden costs (e.g., cloud infrastructure costs, training)? - What are the ongoing operational costs?	- Choosing between managed or self-hosted services - Cloud provider costs for storage and bandwidth
Flexibility & Extensibility	Can the solution easily adapt to future changes in the business or technical environment?	- How adaptable is this technology to future needs or changes? - Does the architecture allow for easy integration with other services or tools? - Can we extend it if necessary?	- Using RESTful APIs for easy future integration - Designing a system with plugin architecture
Vendor Lock-In	Does the solution create a dependency on a specific vendor, or can it be easily migrated?	- Is the technology tied to a specific cloud vendor or service? - How hard is it to switch to another provider if necessary? - What are the exit strategies if the vendor changes terms or pricing?	- Choosing an open-source database versus a proprietary one - Using a cloud-native service with high dependency on a single vendor
User Experience (UX)	Does the solution meet the UX requirements in terms of speed, usability, and functionality?	- How will this impact the end-user experience? - Does this solution support intuitive, fast, and responsive interactions? - Will it provide a consistent experience across devices and platforms?	- Building a mobile-first web app - Designing an interactive, real-time dashboard
Compliance & Regulations	Does the solution meet industry-specific regulations and compliance standards?	- Does this solution comply with legal or industry-specific regulations (e.g., GDPR, HIPAA)? - Does it have auditing, logging, and data retention mechanisms in place?	- Implementing secure data storage for healthcare data - Ensuring GDPR compliance for user data

How to Use the Matrix:

Identify Key Criteria

Start by defining the most important factors based on your specific decision. For instance:
- If you're building a system where performance is paramount (e.g., real-time processing), performance and scalability will be high priority.
- For a system that needs rapid development and MVP delivery, focus on development speed and team expertise.
Evaluate Options

Rate each option or technology against each factor. For instance, you could assign weights to each factor based on its importance:
- 1 (low) to 5 (high) for each factor for each option. Example: If performance is the highest priority, give it a weight of 5. Multiply the rating by the factor's weight to get a score for each option.
Consider Trade-offs

There’s rarely a "perfect" solution. The goal is to find the option that delivers the most value relative to your constraints. For instance:
- A system with high performance but low scalability might work for a small-scale project but become problematic as it grows.
- A solution with low development speed but high maintainability might be ideal for long-term projects but slower for quick launches.
Cross-Disciplinary Considerations

Include feedback from cross-functional teams like:
- DevOps: For deployment and scaling concerns.
- QA: For testing considerations.
- Security: For compliance and best practices.
Make an Informed Decision

Summarize the options with scores and the factors that matter most, then make the final decision based on the data and your team’s needs.

Example: Choosing a Messaging System (Kafka vs. RabbitMQ)

Factor	Kafka	RabbitMQ
Performance	5 (Handles high-throughput, low-latency)	3 (Moderate performance for transactional workloads)
Scalability	5 (Highly scalable for large datasets)	3 (Clustering is possible, but not as scalable as Kafka)
Maintainability	3 (More complex to manage at scale)	5 (Easier to maintain for smaller systems)
Reliability	5 (Built for high availability and fault tolerance)	4 (Good fault tolerance, but less resilient than Kafka)
Cost & Resources	4 (Requires significant resources at scale)	5 (Lower cost for smaller applications)
Flexibility	4 (Great for event-driven architecture, but may not be ideal for all scenarios)	5 (Great for flexible message

Final Decision:
If the system requires high throughput and scalability, Kafka might be the best choice.
If the application has lower traffic and requires easier setup, RabbitMQ might be more suitable.

Composite Indexes in MySQL

meet — Tue, 26 Aug 2025 08:45:48 +0000

When creating composite indexes for queries in MySQL, the correct order of columns is crucial for performance optimization. We often focus on columns with higher cardinality and place them first in the index, assuming it will boost performance.

Example: Tasks Table

Consider a tasks table that stores details of tasks assigned to users, with a large volume of data:

SELECT * FROM tasks 
WHERE user_id = ? AND creation_date BETWEEN ? AND ?;

A typical approach might be to create an index like this:
(creation_date, user_id)

But cardinality is not the only factor to consider when creating composite indexes. A wrongly ordered index can lead to significant performance issues, such as slower queries and even full table scans.

Why Cardinality Isn’t the Only Consideration

Although creation_date might have high cardinality, the query structure (equality vs. range vs. sorting) plays a significant role in determining the optimal index order.

Since user_id is used in an equality condition, it should come first in the index as it is highly selective. The range condition on creation_date (e.g., BETWEEN ? AND ?) should follow because range conditions are less efficient than equality checks.

Correct Index:

(user_id, creation_date)

Learnings:

Start with equality filters, followed by range filters, and end with columns used for sorting.
- Without sorting inclusion, MySQL may have to perform an extra sort on the result set.
Always test with the specific queries using production data and EXPLAIN plan to find the optimal index for your workload.

Embedded-server : undertow basics

meet — Tue, 19 Aug 2025 11:31:15 +0000

In modern Java web application development, choosing the right embedded server and understanding its concurrency model can significantly impact your app's scalability and performance. This post explores what embedded servers are, compares key concurrency models, and offers an inside look at how Undertow — a high-performance embedded server — works under the hood.

What Are Embedded Servers?

Embedded servers are web servers integrated directly into an application instead of operating as standalone services. This allows developers to build self-contained applications that are easier to develop, deploy, and test.

Some popular embedded servers in the Java ecosystem include:

Tomcat: The classic servlet container, known for robustness.
Jetty: Flexible and modular, supports both synchronous and asynchronous servlets.
Undertow: Lightweight, designed for reactive and asynchronous workloads.
Netty: A low-level asynchronous event-driven network framework, powering custom protocols and reactive HTTP servers.

Concurrency Models: Thread-per-Request vs. Event Loop

How a server manages multiple simultaneous requests drastically affects performance and scalability. Two main concurrency models prevail:

Thread-per-Request Model

Assigns one thread per incoming request
Threads handle the full request lifecycle, including any blocking calls (like database queries)
Concurrency directly limited by thread pool size
Can lead to thread exhaustion if many requests block simultaneously
Found in traditional servers like Tomcat and Jetty
Easier programming model but less scalable under heavy load

Event Loop Model

Uses a small, fixed number of event loop threads
Each event loop handles many connections via non-blocking, asynchronous I/O
Blocking or long-running tasks are offloaded to worker thread pools
Enables handling thousands of concurrent connections efficiently
Common in servers like Undertow and Netty
Requires writing asynchronous or reactive code but yields superior scalability

How Undertow Works Internally

Undertow is designed for ultra-low latency and high throughput, making it well-suited for modern reactive applications.

Undertow’s threading model distinguishes two main types of threads that work together to deliver high performance and scalability:

IO Threads (Event Loop Threads)

These are the event loop threads in Undertow.
The number of IO threads is typically set equal to the number of CPU cores.
Each IO thread runs an event loop responsible for handling all non-blocking network I/O operations on multiple socket connections.
Every incoming request on a connection is initially handled by the IO thread bound to that connection.
IO threads never perform blocking operations directly to avoid stalling the event loop.
Their job is to efficiently multiplex many concurrent connections with minimal threads.

Worker Threads (Core Threads)

Worker threads come from a dedicated worker thread pool.
These threads handle blocking or long-running tasks, such as database queries, file operations, or heavy computations.
When a blocking task arises, Undertow dispatches the work from the IO thread to a worker thread.
Once completed, the worker thread posts a callback back to the same IO thread to resume request processing.
The worker thread pool size is usually larger than the number of IO threads, for example, 8 times the IO thread count.

Thread Type	Function	Thread Count (Typical)	Is it Event Loop?
IO Threads	Run non-blocking event loops, manage connections	Equal to CPU cores	Yes, these are the event loop threads
Worker Threads	Handle blocking/long-running operations	Multiple times IO thread count	No

Here’s what happens under the hood:

IO Threads Are Event Loops: Undertow runs a group of IO (input/output) threads, each executing an event loop handling multiple socket connections asynchronously.
Connection Thread Affinity: Each network connection is permanently assigned to a single IO thread, ensuring all logic and IO for that connection stay on one thread, avoiding concurrency hazards.
Worker Threads for Blocking Work: When the processing requires blocking operations (database calls, file IO), Undertow dispatches work to a worker thread pool to keep IO threads free for non-blocking tasks.
Callback Mechanism: After completing blocking operations, the worker thread posts a callback to the original IO thread to continue request processing.
Thread Count Balance: Typically, Undertow configures IO threads equal to CPU cores, with a larger pool of worker threads to handle blocking workloads efficiently.

This hybrid approach preserves responsiveness and throughput by separating lightweight asynchronous IO from heavyweight blocking operations.

Comparing the Models: At a Glance

Feature	Thread-per-Request	Event Loop (Undertow)
Threads per request	One	Few event loop threads serve many
Handling blocking calls	Threads blocked	Blocking offloaded to worker threads
Scalability	Limited by thread pool size	High concurrency with fewer threads
Programming complexity	Simpler synchronous code	Requires async/reactive programming

How Undertow Supports Both Blocking and Non-blocking Paradigms

Undertow is built to handle web requests in two different ways, giving you flexibility depending on your application's needs: non-blocking (asynchronous) and blocking (synchronous) processing.

Non-blocking Mode — The Efficient Event Loop

By default, Undertow uses IO threads known as event loops to manage incoming requests. These event loop threads work asynchronously using non-blocking IO, which means:

One thread can manage many connections at once without waiting or getting stuck.
When your request processing involves operations that take time (like database calls), Undertow offloads this work to a special pool of worker threads.
Once that work finishes, a callback is sent back to the original event loop thread to pick up where it left off and send the response.

This method is very efficient for handling large numbers of concurrent connections because the event loop threads are never blocked waiting for slow operations.

Blocking Mode — Support for Traditional Synchronous Code

Some applications, especially traditional Spring Boot projects using Spring MVC, work in a blocking way:

Your controller methods and other request handlers run synchronously, meaning they wait (block) until operations finish.
Undertow supports this by letting you switch into blocking mode using a call to HttpServerExchange.startBlocking().
When blocking mode is used, the request handling is moved off the event loop threads and onto worker threads.
This way, even though your code blocks while waiting for operations, it does not freeze the important event loop threads that keep the server responsive.

What Happens in a Non-Reactive Spring Boot App?

If you use Undertow as the embedded server in a typical non-reactive Spring Boot application:

Incoming requests land on Undertow’s non-blocking IO event loop threads.
Since Spring MVC uses blocking, synchronous request handlers, Undertow automatically dispatches these requests away from the event loop threads to its worker thread pool.
This dispatch ensures that blocking processing happens on worker threads, keeping the event loop threads free to handle other incoming connections efficiently.
The whole “switch to blocking mode” and running on worker threads is managed internally by Undertow as part of its integration with Spring Boot.
This lets you write traditional blocking code without worrying about blocking event loop threads yourself.

This approach strikes a balance between traditional blocking programming and efficient server resource usage.

Why Is This Important?

The non-blocking event loop model is great for scalability and handling thousands of concurrent connections efficiently.
The blocking mode keeps compatibility with existing synchronous code and frameworks.
Undertow’s hybrid model allows you to build on top of proven blocking paradigms without sacrificing event loop performance.
You get the best of both worlds: wide compatibility and high scalability.

If your application has mostly synchronous, blocking code (like typical Spring MVC controllers), Undertow will safely handle blocking calls on worker threads so the event loop threads remain free. If you want even better scalability with highly concurrent workloads, consider using reactive programming models where you can take full advantage of the event loop’s non-blocking nature.

RabbitMQ Basic Overview

meet — Sun, 01 Aug 2021 07:59:08 +0000

RabbitMQ is a messaging broker and supports AMQP 0-9-1 (Advanced Message Queuing Protocol) protocol.

RabbitMQ allows for communication by providing support for applications that publish a message to it (i.e broker) and it delivers the messages to consumer applications.

RabbitMQ main components/concepts:

Exchange

Exchanges are entities where messages are sent.
It take a message and route it into zero or more queues based on routing algorithm.
Routing algorithm depends on exchange type and rules called bindings.
Queues are bound to exchanges by using the routing key.

Exchange Type

AMQP 0-9-1 brokers provide four exchange types:

Default Exchange

The default exchange is a direct exchange with no name (empty string) predeclared by the broker.
It has one special property that makes it very useful for simple applications: every queue that is created is automatically bound to it with a routing key which is the same as the queue name.

Direct Exchange

A direct exchange delivers messages to queues based on the message routing key.

Direct exchanges can be used to distribute tasks between multiple workers as seen in above diagram.

Publisher 1 publishes messages with 'emails.marketing' routing key to direct exchange.
Queue 2 is bounded to direct exchange with 'emails.marketing' routing key, so exchange forwards the such messages to Queue 2.
Consumer 3 is listening to Queue 2 and will hence receive such messaged.

Direct exchanges can be used to distribute messages between multiple workers [i.e consumers] as seen in above diagram.
These messages are load balanced between consumers in a round robin manner and not between queues.

Publisher 2 publishes messages with 'emails.sales' routing key to direct exchange.
Queue 1 and Queue 3 are bounded to direct exchange with 'emails.sales' routing key, so exchange makes 2 copies of received messages and forwards one each to to Queue 1 and Queue 2.
Consumer 1 and Consumer 2 are listening to Queue 1. Each of them will receive unique message for processing in round robin manner. That is a single message cannot be consumed by multiple consumers.

Fanout Exchange

A fanout exchange routes messages to all of the queues that are bound to it and the routing key is ignored.

If N queues are bound to a fanout exchange, when a new message is published to that exchange a copy of the message is delivered to all N queues.
Fanout exchanges are ideal for the broadcast routing of messages.

Topic Exchange

Topic exchanges route messages to one or many queues based on matching between a message routing key and the pattern that was used to bind a queue to an exchange.

Two special cases for binding keys in topic exchange:

* (star) can substitute for exactly one word.
# (hash) can substitute for zero or more words and if used alone to bind queue, it will behave like fan-out exchange

The first word in the routing key here describes a communication-method, second a business function and third personalized: [communication-method].[business].[personalized].

As in above diagram,
Colons can be used to align columns.

Routing Key	Queue Delivered To
sms.marketing.all	Q2
emails.sales.specific	Q1,Q3
sms.sales.specific	Q3
sms.sales.specific.all	Q3
emails.sales.specific.all	Q3
emails.marketing.specific.all	Lost message

References

https://www.rabbitmq.com/tutorials/amqp-concepts.html