Recently a planned AWS Aurora database failover/master reboot caused database connection failures in one of our services which caused me to delve deeper into how MySql driver manages connections under the hood.
Monitoring the health of your application in production is a crucial aspect of software development because at any given point in time, you want to be reasonably certain about how your business critical application is performing and you want to be alerted to any problems that might be brewing up in the application before your customers do.
…the whole business process can be divided into smaller asynchronous sub-processes with each one feeding i.e. “piping” its output into the input of the subsequent process(es). At each stage some processing is done for e.g. data enriching, filtering etc and this processing generically is termed as a “filter”.
The way logging and instrumentation in code has traditionally been done is something like the below, say, I want to profile my application service method called “PeriodCloseReportAsync()” that gets called from my MVC controller action: This can be ok to a certain extent as long as the application is simple enough and you only intend […]
Seeing as micro-service architectures are all the rage these days, I decided to dip into it by building…
In a multi-tenant environment the application database is usually partitioned by tenants. This is done to achieve isolation and scalability. The problem of course is how do you route tenant requests to the correct databases?