Fix readme typos (#191)

* fix cache README typos

* fix monitoring README typos

packages/cache/README.md

@@ -22,15 +22,15 @@ The package exports **in memory cache service** and **remote cache service**.
 ## Table of contents
 - [In Memory Cache](#in-memory-cache) - super fast in memory caching system based on [LRU cache](https://www.npmjs.com/package/lru-cache)
 - [Redis Cache](#redis-cache) - Caching system based on [Redis](https://www.npmjs.com/package/@multiversx/sdk-nestjs-redis)
-- [Cache Service](#cache-service) - MultiversX caching system with combines in memory an readis cache forming a two layers caching system
+- [Cache Service](#cache-service) - MultiversX caching system which combines in-memory and Redis cache, forming a two-layer caching system
 
 ## In memory cache
 In memory cache, available through `InMemoryCacheService`, is used to read and write data from and into the memory storage of your Node.js instance.
 
 
-*Note that if you have multiple instances of you application you must sync local cache across all your instances.*
+*Note that if you have multiple instances of your application you must sync local cache across all your instances.*
 
-Lets take as an example a ConfigService which loads some non crucial configuration from database and can be cached for 10 seconds. 
+Let's take as an example a ConfigService that loads some non-crucial configuration from the database and can be cached for 10 seconds. 
 
 Usage example: 
 ```typescript
@@ -113,7 +113,7 @@ When the `.loadConfiguration()` method is called for the first time, the `.getCo
 - **Returns:** A `Promise` that resolves to the updated or newly created value.
 
 ## Redis Cache
-Redis cache, available through `RedisCacheService`, is a caching system build ontop of Reids. It is used to share cache related information among multiple microservices.
+Redis cache, available through `RedisCacheService`, is a caching system build ontop of Redis. It is used to share cache related information among multiple microservices.
 
 Let's build the same config loader class but with data shared across multiple clusters using Redis. The implementation is almost identical since both `InMemoryCache` and `RedisCache` have similar class structure.
 
@@ -190,5 +190,5 @@ export class ConfigService {
 **Note:** These are just some of the methods available in the `RedisCacheService` class.
 
 ## Cache Service
-Cache service is using both [In Memory Cache](#in-memory-cache) and [Redis Cache](#redis-cache) to form a two layer caching system.
+Cache service is using both [In Memory Cache](#in-memory-cache) and [Redis Cache](#redis-cache) to form a two-layer caching system.
 

packages/monitoring/README.md

@@ -3,7 +3,7 @@
 # MultiversX NestJS Microservice Monitoring Utilities
 
 This package contains a set of utilities commonly used for monitoring purposes in the MultiversX Microservice ecosystem. 
-The package relies on prometheus to aggregate the metrics and it is using [prom-client](https://www.npmjs.com/package/prom-client) as a client for it.
+The package relies on Prometheus to aggregate the metrics and it is using [prom-client](https://www.npmjs.com/package/prom-client) as a client for it.
 
 ## Installation
 
@@ -26,11 +26,11 @@ const profiler = new PerformanceProfiler();
 await doSomething();
 const profilerDurationInMs = profiler.stop();
 
-console.log(`doSomething() method exection time lasted ${profilerDurationInMs} ms`);
+console.log(`doSomething() method execution time lasted ${profilerDurationInMs} ms`);
 ```
 
 The `.stop()` method can receive two optional parameters:
-- `description` - text used for default loggin. Default: `undefined`
+- `description` - text used for default logging. Default: `undefined`
 - `log` - boolean to determine if log should be printed. If `log` is set to true, the logging class used to print will be `Logger` from `"@nestjs/common"`.` `Default: `false`
 
 
@@ -46,7 +46,7 @@ The output of the code above will be "`doSomething() execution time: 1.532ms`"
 ---
 
 ### Cpu Profiler
-`CpuProfiler` is a class exported by the package that allows you to measure the CPU execution time of your code. Javascript being single threaded you must be careful how much CPU time you spend on some operations because it can slow down your process or even block it.
+`CpuProfiler` is a class exported by the package that allows you to measure the CPU execution time of your code. Given that JavaScript is a single-threaded language, it's important to be mindful of the amount of CPU time allocated to certain operations, as excessive consumption can lead to slowdowns or even blockages in your process.
 
 ```typescript
 import { CpuProfiler } from '@multiversx/sdk-nestjs-monitoring';
@@ -55,11 +55,11 @@ const profiler = new CpuProfiler();
 await doHttpRequest()
 const profilerDurationInMs = profiler.stop();
 
-console.log(`doHttpRequest() method exection time lasted ${profilerDurationInMs} ms`);
+console.log(`doHttpRequest() method execution time lasted ${profilerDurationInMs} ms`);
 ```
 
 The `.stop()` method can receive two optional parameters:
-- `description` - text used for default loggin. Setting the description will trigger automatically printing the value of `PerformanceProfiler`. Default: `undefined`
+- `description` - text used for default logging. Setting the description automatically triggers the printing of the `PerformanceProfiler` value. Default: `undefined`
 
 ```typescript
 import { CpuProfiler } from '@multiversx/sdk-nestjs-monitoring';
@@ -77,18 +77,18 @@ The output of the code above will be <br/>
 `doHttpRequest() execution time: 100ms, CPU time: 1ms`
 `doSomethingCpuIntensive() execution time: 20ms, CPU time 18ms`
 
-*Note that a big execution time does not necessarily have an impact on the CPU load of the application, that means that for example while waiting for an HTTP request for example, the Javascript thread can process other things. That is not the case for CPU time because when a method consumes a lot of CPU time, Javascript will not be able to process other things meanwhile and it can freeze until the CPU consuming task is done.*
+*Note that a big execution time does not necessarily have an impact on the CPU load of the application. That means that, for example, while waiting for an HTTP request, the JavaScript thread can process other things. That is not the case for CPU time. When a method consumes a lot of CPU time, Javascript will not be able to process other tasks, potentially causing a freeze until the CPU-intensive task is complete.*
 
 ---
 
 ## Interceptors
 The package provides a series of [Nestjs Interceptors](https://docs.nestjs.com/interceptors) which will automatically log and set the CPU and overall duration for each request in a prom histogram ready to be scrapped by Prometheus.
 
-`LoggingInterceptor` interceptor will set in a prometheus histogram the request execution time of each request using [performance profilers](#performance-profiler).
+`LoggingInterceptor` interceptor will set the execution time of each request in a Prometheus histogram using [performance profilers](#performance-profiler).
 
-`RequestCpuTimeInterceptor` interceptor will set in a prometheus histogram the request CPU execution time of each request using [cpu profiler](#cpu-profiler).
+`RequestCpuTimeInterceptor` interceptor will set the CPU execution time of each request in a Prometheus histogram using [cpu profiler](#cpu-profiler).
 
-*Both interceptors expect as an argument an instance of `metricsService` class.*
+*Both interceptors expect an instance of `metricsService` class as an argument.*
 
 ```typescript
 import { MetricsService, RequestCpuTimeInterceptor, LoggingInterceptor } from '@multiversx/sdk-nestjs-monitoring';
@@ -108,7 +108,7 @@ async function bootstrap() {
 
 ## MetricsModule and MetricsService
 
-`MetricsModule` is a [Nestjs Module](https://docs.nestjs.com/modules) responsible for aggregating metrics data through `MetricsService` and exposing them to be consumed by Prometheus. `MetricsService` is extensible, you can define and aggregate your own metrics and expose them. By default it exposes a set of metrics created by the interceptors specified [here](#interceptors). Most of the Multiversx packages expose metrics by default through this service, for example [@multiversx/sdk-nestjs-redis](https://www.npmjs.com/package/@multiversx/sdk-nestjs-redis) automatically tracks the execution time of each redis query, overall redis health and much more, and expose sends them to `metricsService`.
+`MetricsModule` is a [Nestjs Module](https://docs.nestjs.com/modules) responsible for aggregating metrics data through `MetricsService` and exposing them to be consumed by Prometheus. `MetricsService` is extensible, you can define and aggregate your own metrics and expose them. By default it exposes a set of metrics created by the interceptors specified [here](#interceptors). Most of the Multiversx packages expose metrics by default through this service. For example [@multiversx/sdk-nestjs-redis](https://www.npmjs.com/package/@multiversx/sdk-nestjs-redis) automatically tracks the execution time of each redis query, overall redis health and much more, by leveraging the `MetricsService`.
 
 ### How to instantiate the MetricsModule and expose metrics endpoints for Prometheus
 
@@ -164,13 +164,13 @@ export class ApiMetricsService {
     return baseMetrics + '\n' + currentMetrics;
   }
 
-  setHearthbeatDuration(app: string, duration: number) {
+  setHeartbeatDuration(app: string, duration: number) {
     ApiMetricsService.heartbeatsHistogram.labels(app).observe(duration);
   }
 }
 ```
 
 The only change we have to do is that we need to instantiate this class and call `.getMetrics()` method on it to return to us both default and our new custom metrics.
 
-The `.setHearthbeatDuration()` method will be used in our business logic whenever we want to add a new value to that histogram.
+The `.setHeartbeatDuration()` method will be used in our business logic whenever we want to add a new value to that histogram.