# Performance Testing of Event-Driven Microservices ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png) URL:: https://medium.com/capital-one-tech/performance-testing-of-event-driven-microservices-f5de74305985 Author:: Sai Prakash ## Highlights > Tech professionals have experienced firsthand the pitfalls of building such complex monolithic applications. Issues include, but are not limited to: > Large monoliths are difficult to maintain and tracking down software bugs becomes a tedious task. > They share common libraries. The update or addition of libraries can lead to dependency issues that if not handled properly, create an inconsistent system. This can also require a whole system reboot to update, which in turn leads to increased downtimes. > Monoliths represent a technology lock-down for developers since they’re bound to the software language and frameworks of the original application. > Monoliths limit scalability. The usual strategy of creating multiple instances to handle incoming traffic may not work here due to complexity and dependency of resources. ([View Highlight](https://instapaper.com/read/1411963111/16379183)) > anti-monolithic patterns, microservices-based architecture being one of them. ([View Highlight](https://instapaper.com/read/1411963111/16379186)) > A microservice is a “minimal independent process interacting via messages. ([View Highlight](https://instapaper.com/read/1411963111/16379190)) > Microservices-based architecture is a more recent extension of service-oriented architecture (SOA). However, a key difference is that SOA focuses more on reusability and segregation, whereas microservices-based architecture focus more on replacing large applications with systems that can incrementally evolve and are easier to manage using smaller services. ([View Highlight](https://instapaper.com/read/1411963111/16379195)) > Often, microservices have smart endpoints and are event-driven; i.e. based on an event, they receive a request, process it, and generate a response accordingly. Less frequently, microservices with HTTP endpoints expose APIs to external applications ([View Highlight](https://instapaper.com/read/1411963111/16379197)) > Consider a money transfer transaction which involves various components and interfaces like a web application, REST API, a microservice, a message broker, and a NoSQL database. > 1. User logs into the web application > 2. User performs a transaction > 3. Message is sent to the TRANSACTION INITIATED topic of the message broker > 4. All the subscribed queues receive messages and the RECORDCREATOR microservice -listening to one of those queues- analyzes the message > 5. A transaction is created in the database, and sends a message to the RECORD CREATED topic of the message broker > 6. FILECREATOR microservice then picks up the message and generates a data file > User transaction flow in a microservice based architecture ([View Highlight](https://instapaper.com/read/1411963111/16379244)) > For a quality engineer to test a RECORDCREATOR microservice, send a message to the message broker and validate the data inserted into a NoSQL database. ([View Highlight](https://instapaper.com/read/1411963111/16379263)) > To performance test a RECORDCREATOR microservice, send numerous messages to Amazon SNS topic using JMeter. Then calculate the service throughput with the help of SQS metrics such as NumberOfMessagesSent, NumberOfMessagesDeleted, ApproximateNumberOfMessagesVisible from Amazon CloudWatch and the response time metric based on the timestamp difference of the message from Amazon SQS and a transaction created in the NoSQL database. A point to note here is, a valid message is deleted from the SQS only when the microservice processes and acknowledges the message, before it’s visibility timeout expires. > For reference, CloudWatch metric definitions for Amazon Simple Queue Service are: > NumberOfMessagesSent — The number of messages added to a queue. > NumberOfMessagesDeleted — The number of messages deleted from a queue. > ApproximateNumberOfMessagesVisible — The number of messages available for retrieval from the queue. ([View Highlight](https://instapaper.com/read/1411963111/16379279)) --- Title: Performance Testing of Event-Driven Microservices Author: Sai Prakash Tags: readwise, articles date: 2024-01-30 --- # Performance Testing of Event-Driven Microservices ![rw-book-cover](https://readwise-assets.s3.amazonaws.com/static/images/article2.74d541386bbf.png) URL:: https://medium.com/capital-one-tech/performance-testing-of-event-driven-microservices-f5de74305985 Author:: Sai Prakash ## AI-Generated Summary None ## Highlights > Tech professionals have experienced firsthand the pitfalls of building such complex monolithic applications. Issues include, but are not limited to: > Large monoliths are difficult to maintain and tracking down software bugs becomes a tedious task. > They share common libraries. The update or addition of libraries can lead to dependency issues that if not handled properly, create an inconsistent system. This can also require a whole system reboot to update, which in turn leads to increased downtimes. > Monoliths represent a technology lock-down for developers since they’re bound to the software language and frameworks of the original application. > Monoliths limit scalability. The usual strategy of creating multiple instances to handle incoming traffic may not work here due to complexity and dependency of resources. ([View Highlight](https://instapaper.com/read/1411963111/16379183)) > anti-monolithic patterns, microservices-based architecture being one of them. ([View Highlight](https://instapaper.com/read/1411963111/16379186)) > A microservice is a “minimal independent process interacting via messages. ([View Highlight](https://instapaper.com/read/1411963111/16379190)) > Microservices-based architecture is a more recent extension of service-oriented architecture (SOA). However, a key difference is that SOA focuses more on reusability and segregation, whereas microservices-based architecture focus more on replacing large applications with systems that can incrementally evolve and are easier to manage using smaller services. ([View Highlight](https://instapaper.com/read/1411963111/16379195)) > Often, microservices have smart endpoints and are event-driven; i.e. based on an event, they receive a request, process it, and generate a response accordingly. Less frequently, microservices with HTTP endpoints expose APIs to external applications ([View Highlight](https://instapaper.com/read/1411963111/16379197)) > Consider a money transfer transaction which involves various components and interfaces like a web application, REST API, a microservice, a message broker, and a NoSQL database. > 1. User logs into the web application > 2. User performs a transaction > 3. Message is sent to the TRANSACTION INITIATED topic of the message broker > 4. All the subscribed queues receive messages and the RECORDCREATOR microservice -listening to one of those queues- analyzes the message > 5. A transaction is created in the database, and sends a message to the RECORD CREATED topic of the message broker > 6. FILECREATOR microservice then picks up the message and generates a data file > User transaction flow in a microservice based architecture ([View Highlight](https://instapaper.com/read/1411963111/16379244)) > For a quality engineer to test a RECORDCREATOR microservice, send a message to the message broker and validate the data inserted into a NoSQL database. ([View Highlight](https://instapaper.com/read/1411963111/16379263)) > To performance test a RECORDCREATOR microservice, send numerous messages to Amazon SNS topic using JMeter. Then calculate the service throughput with the help of SQS metrics such as NumberOfMessagesSent, NumberOfMessagesDeleted, ApproximateNumberOfMessagesVisible from Amazon CloudWatch and the response time metric based on the timestamp difference of the message from Amazon SQS and a transaction created in the NoSQL database. A point to note here is, a valid message is deleted from the SQS only when the microservice processes and acknowledges the message, before it’s visibility timeout expires. > For reference, CloudWatch metric definitions for Amazon Simple Queue Service are: > NumberOfMessagesSent — The number of messages added to a queue. > NumberOfMessagesDeleted — The number of messages deleted from a queue. > ApproximateNumberOfMessagesVisible — The number of messages available for retrieval from the queue. ([View Highlight](https://instapaper.com/read/1411963111/16379279))