How to deal with cache stampede in MySQL

The Cache stampede problem (also called dog-piling, cache miss storm, or cache choking) is not a big problem for small scale systems but is a common headache for large scale applications with millions of requests. It has the potential to bring down the entire system in a matter of seconds.

What is Cache StampedeConsider an item that is expensive to generate, and is cached. When the cache expires, the application usually regenerates the item and writes to the cache, and continue as normal. Under very high load, when the cached item expires, multiple requests will get a cache miss and all of them will try to regenerate the cache simultaneously, which will cause a high load in the database.
Cache Stampede can occur with any cache including MySQL query cache, or any external cache like Redis or Memcached. It is ok to ignore this problem when your application is small scale but very important to address the issues as you scale up. 
Cache stampede can be seen as random spikes in the CPU usage …

The DRY (Don't Repeat Yourself) Principle

DRY stands for Don't Repeat Yourself, which basically means to avoid writing duplicate code. If you find a block of code that is repeated multiple places, consider using abstraction or moving the code to a separate method. Similarly, if you use a hard-coded value more than once, try making it a constant. This can be applied to every area of software development including database, unit tests, build systems, and documentation. 
The benefit of the DRY principle is code maintenance. Changing functionalities in the future will be much easier because you don't have to remember all the places where the code needs to be changed. 
An important point to remember here is to not abuse the principle. Duplication is not for code, but for functionality. It means you should never use a standard code for two functionalities that have similar code but are logically unrelated. Doing it will tightly couple two different functionalities together and changing one of them in the future will become ha…

How I learned React.js and Node.js from scratch in a few months

Recently Causematch decided to shift from wordpress based platform to React.js+Node.js stack. Causematch has indeed grown a lot in past few years that wordpress has become unable to handle us. We had to move on.
I was from a backend development background, and hence a complete beginner in javascript and now both our backend and frontend was going to be in js but I was excited anyway to learn all the new stuff.
Looking back now, I have come a long way in both React.js and Node.js. Here are few things that helped me on my way.
Online coursesIt is no secret that there are plenty of online courses online. It took me less than 5 minutes to go to and find a course with good reviews. Here is the one I chose: Keeping an eye on reviews is the key to selecting a good course. 
I was too lazy to attend online classes for Node.js too, but I bought one anyway.

Abstract Factory Pattern

The Abstract Factory Pattern adds another layer of abstraction over the Factory Pattern. It has an Abstract Factory Interface which is implemented by several Factory classes. A Super Factory decides which Factory should be used based on the requirement. Abstract Factory Pattern is one the creational design patterns.

An interface which for creating AbstractProduct objects.ConcreteFactory
Implements AbstractFactory and creates ConcreteProduct objects.AbstractProduct
An interface for type of products.ConcreteProduct
Implements AbstractProduct object. Here is where the actual product code is defined.Client
Uses methods provided by AbstractFactory and AbstractProduct interfaces to create objects. UML Diagram

As you can see in the diagram, There is an AbstractFactory interface which is implemented by 2 factory classes. Client doesn't access the concrete factory classes directly, instead uses the methods provided by AbstractFactory interface. Example

Design Patterns

Do not reinvent the wheel. Just realign it. When it comes to software world, most design level problems are already solved. Design Patterns are blueprints of these solutions which you can customize and use in your application.

Advantages:Tried and tested solutions be experienced developers.It helps improve developer communication. Every developer knows what a 'Singleton' is, right?
Common Design Patterns Creational design patternsAbstract FactoryBuilderFactory MethodObject PoolPrototypeSingleton Structural design patternsAdapterBridgeCompositeDecoratorFacadeFlyweightPrivate Class DataProxy Behavioural design patternsChain of responsibilityCommandInterpreterIteratorMediatorMementoNull ObjectObserverStateStrategyTemplate MethodVisitor

Java 12 is here!

Java has switched to a 6-month release cycle, which means you don't have to wait 3 years for a major Java upgrade. It also means less and manageable changes in each major release. Java 12 has been released recently. Here is a brief overview of new features.

Switch Expressions We all use switch statements, and we know how much it simplifies coding. But still, it required having a break statement after every case expression. As a guy who makes a lot of careless mitsakes, missing break statement after a case is one of the mistakes I make a lot.
switch(month) { case1 : monthStr = "January"; break; case2 : monthStr = "February"; break; case3 : monthStr = "March"; break; case4 : monthStr = "April"; break; }
Now with switch expressions, the switch block is going to look much cleaner and robust.

String monthStr = switch(month) { case1 -> "January"; case2 -> "Fe…

Programmer's Guide to Dealing With Different Time Zones

All programmers have to deal with times and time zones at some point. 

When your product gets wider, it gets more and more difficult to handle and synchronize time between multiple time zones. Being well-informed beforehand might save some pain in the "head" later.

I've compiled a few most important tips to take care of when dealing with time zones. The actual list is definitely much bigger. But consider this a start.
Store Time in UTCStoring local time in the database is okay when your product is small and deals with just one time zone. But when you start dealing multiple time zones and DST(Daylight Saving Time), it gets weirder. Now you have to convert your time to different time zones for different users and you have to maintain all upcoming DST changes. 
Storing time in UTC can save many headaches in the future. The important reason being that the UTC timezone is never affected by DST. So always remember to store time in UTC, and apply the user's timezone when retrie…