Fundamentals
The response codes for HTTP are divided into five categories:
- Informational (100-199)
- Success (200-299)
- Redirection (300-399)
- Client Error (400-499)
- Server Error (500-599)
These codes are defined in RFC 9110. To save you from reading the entire document (which is about 200 pages), here is a summary of the most common ones.
There are various types of databases available. SQL, NoSQL, Timeseries, Engineering database, Key-Vaue, In-Memory, GeoSpatial etc. To be updated.
- Cache Types (In-memory caching, Distributed caching, Client-side caching)
- Cache Strategies (Cache-Aside, Write-Through, Write-Behind, Read-Through)
- Measuring Cache Effectiveness (Calculate the cache hit rate, Analyse cache eviction rate, Monitor data consistency, Determine the right cache expiration time)
- Canary Deployments In software engineering, canary deployment is the practice of making staged releases. We roll out a software update to a small part of the users first, so they may test it and provide feedback. Once the change is accepted, the update is rolled out to the rest of the users.
Benefits of Canary Deployments Why go to the trouble of implementing a canary strategy? The benefits are many:
A/B testing: we can use the canary to do A/B testing. In other words, we present two alternatives to the users and see which gets better reception.
Capacity test: it’s impossible to test the capacity of a large production environment. With canary deployments, capacity tests are built-in. Any performance issues we have in our system will begin to crop up as we slowly migrate the users to the canary.
Feedback: we get invaluable input from real users.
No cold-starts: new systems can take a while to start up. Canary deployments slowly build up momentum to prevent cold-start slowness.
No downtime: like blue-green deployments, a canary deployment doesn’t generate downtime.
Easy rollback: if something goes wrong, we can easily roll back to the previous version.