Implementation of distributed cache

-
One of the things that we can't escape while developing a system, is the use of database to store data. However, we ought to know that the frequency of database access will directly affect our system's performance.

 This is where caching comes in. Caching not only reduces the number of calls required to access the database, but also to increase the speed we could retrieve the data that we need. Cache is a storage pattern which allows for fast retrieval of data which we need frequently, and it should not be a set of data which changes constantly.

 In case of ASP.NET Core, there are 2 types of caching that we can use; in-memory cache & distributed cache. In-memory cache means that the cache is available for access within the application itself only. If we are building a system that contains multiple apps. which spread across multiple servers, each app. will have its own cache, which might be redundant, since all of them utilize the same data. This is where distributed cache comes in.

 When I first wanted to work on distributed cache, one of the problems involves cache refreshing. If we have a number of apps. accessing the cache, how could we ensure only one of them is refreshing the cache? 2 solutions came up at that time,

 1. Attempt to use cache-lock to ensure only 1 client is doing the refresh, or
2. Leave the refresh job to a new process

 Since our system is already utilizing AWS services, it crossed my thought that we might try to execute option 2 using the services in AWS. 2 things are required to build a self-triggered event (periodically):

 1. A Windows task-scheduler alike tool (CloudWatch)
2. A process to refresh the cache (Lambda)

 Well, if you are looking for a more budget solution, you could easily build your own cron job (e.g. console app. & task scheduler in Windows). If not, $1.00 per million custom events wouldn't exactly put a dent in your pocket as well.

Comments

Post a Comment

Popular posts from this blog

ASP.NET Core service locator pattern

-
There are many posts out there which specifically say that we should not use service locator pattern (unless necessary), which we would not be able to determine the dependencies during compile time because the dependencies are hidden. However, I am going to point out an issue in case if you need to use it, in the context of ASP.NET Core projects. I have a class Foo , which will be bind to IFoo , and I will need to configure a named HttpClient for that class via the following extension,   services.AddHttpClient<IFoo, Foo>(); If we do the above, Foo will be treated as an object which is Singleton injected. In case you are not aware, we cannot inject services which has a smaller lifespan than the service itself. Hence, we cannot inject services which are transient or scoped into Foo . Here comes the problem, what should we do? That's where service locator pattern comes to the rescue! There might be other way, but let's say we decide to use the service locator provide
Read more

Caching and generic query using NHibernate [.NET Core]

-
One of the important aspects in API design is to reduce the number of fetch request to database. NHibernate provides 2 levels of caching, with the first level cache persist through a session only, while the 2nd level cache persists across multiple sessions. The second level cache can be implemented by installing the NuGet package of NHibernate.Caches.SysCache . Then, it involves some configuration setup to utilize the cache feature. However, there is an alternative way that exists in .NET Core which we could use to build a simpler cache. The caching that we could use is IMemoryCache . Firstly, we could setup the cache during  ConfigureServices . public void ConfigureServices(IServiceCollection services) { services.AddMemoryCache(); } Then, assuming we want to retrieve all the records from a table called DailySales , and we want to keep the records in the cache for 1 minute, we could do the following. private readonly IMemoryCache cache; public DBHelper(IMemory
Read more

Ways to perform eager loading via NHibernate

-
By default we know that lazy loading is enabled in NHibernate. So, let's say if we decide to keep the default, how do we enable eager loading with NHibernate? There are 2 ways to do that (there are more, but I will mention 2 that you will commonly see): 1.  Query<Entity>().Fetch(x => x.ClassA).Fetch(x => x.ClassB); 2. var tempQuery =  Query<Entity>().Fetch(x => x.ClassA).ToFuture();      Query<Entity>(). Fetch(x => x.ClassB).ToFuture();     var entityList =  tempQuery   .ToList(); Do note that Fetch is used to fetch reference, while FetchMany is used to fetch collection. If you are wondering what is the difference between 1 and 2, it is the use of ToFuture to split the SQL statement to multiple queries. The problem with multiple Fetch in a single LINQ query is that it would result in Cartesian product of the main object, in this case, Entity  . Hence, it is not recommended to use multiple Fetch in a single query, but rather use method 2.
Read more