Improvements to backend roadmap content (#6000)
* Update pick-a-language@2f0ZO6GJElfZ2Eis28Hzg.md * Update repo-hosting-services@NvUcSDWBhzJZ31nzT4UlE.md removed a biased (by Bitbucket) link and put one by a regular guy * Update caching@ELj8af7Mi38kUbaPJfCUR.md added a warning for caching * Update server-side@z1-eP4sV75GBEIdM4NvL9.md - removed a deprecated article since caching is a complex topic I added links about strategies, Distributed ones and example of Hibernate 1st/2nd level caches * New content "monitoring" node * Update monitoring@QvMEEsXh0-rzn5hDGcmEv.md * Update monolithic-apps@Ke522R-4k6TDeiDRyZbbU.md * Update soa@tObmzWpjsJtK4GWhx6pwB.md added a simpler link because the link to the reference is probably not going to be read by many * added another link to architectural-patterns@tHiUpG9LN35E5RaHddMv5.md * Service mesh - fixed broken linkpull/6304/head
parent
b1409e6b91
commit
9f69a8de50
9 changed files with 33 additions and 6 deletions
@ -1,3 +1,5 @@ |
|||||||
# Caching |
# Caching |
||||||
|
|
||||||
Caching is a technique of storing frequently used data or information in a local memory, for a certain time period. So, next time, when the client requests the same information, instead of retrieving the information from the database, it will give the information from the local memory. The main advantage of caching is that it improves the performance by reducing the processing burden. |
Caching is a technique of storing frequently used data or results of complex computations in a local memory, for a certain period. So, next time, when the client requests the same information, instead of retrieving the information from the database, it will give the information from the local memory. The main advantage of caching is that it improves performance by reducing the processing burden. |
||||||
|
|
||||||
|
NB! Caching is a complicated topic that has obvious benefits but can lead to pitfalls like stale data, cache invalidation, distributed caching etc |
||||||
|
@ -1 +1,18 @@ |
|||||||
# Monitoring |
# Monitoring |
||||||
|
|
||||||
|
Distributed systems are hard to build, deploy and maintain. They consist of multiple components which communicate with each other. In parallel to that, users use the system, resulting in multiple requests. Making sense of this noise is important to understand: |
||||||
|
- how the system behaves |
||||||
|
- is it broken |
||||||
|
- is it fast enough |
||||||
|
- what can be improved |
||||||
|
|
||||||
|
A product can integrate with existing monitoring products (APM - application performance management). They can show a detailed view of each request - its user, time, components involved, state(error or OK) etc. |
||||||
|
|
||||||
|
We can build dashboards with custom events or metrics according to our needs. Automatic alert rules can be configured on top of these events/metrics. |
||||||
|
|
||||||
|
A few popular tools are Grafana, Sentry, Mixpanel, NewRelic etc |
||||||
|
|
||||||
|
- [@article@Observability vs Monitoring?](https://www.dynatrace.com/news/blog/observability-vs-monitoring/) |
||||||
|
- [@article@What is APM?](https://www.sumologic.com/blog/the-role-of-apm-and-distributed-tracing-in-observability/) |
||||||
|
- [@article@Top monitoring tools 2024](https://thectoclub.com/tools/best-application-monitoring-software/) |
||||||
|
- [@article@Caching strategies](https://medium.com/@genchilu/cache-strategy-in-backend-d0baaacd2d79) |
||||||
|
Loading…
Reference in new issue