Application Flow
The following concepts are important to fully understand the core structure and data flow inside the application.
Most communication comes from the frontend that requests to fetch or manipulate data. However, there are some things that happen asynchronously behind the scene like the cache key invalidation via Message Queue.
This gives you a small peek at everything happening inside the "Magic Box" behind the API Gateway that the frontend doesn't (and shouldn't) know about.
Cache Hit
The most simple and best case scenario when it comes to fetching data! Requests are routed from the frontend through the
API Gateway to the Cache API.
The entire data object is found in the cache and directly returned to the frontend. There is no faster option.
Cache Miss
Same starting point as the previous scenario, however this time there is no data found in the cache! This can happen when new data has recently been created or modified, or a cache entry expired if TTL (Time To Live) is configured.
The Cache API has to request the same data from the Database API now. The Database API then has to communicate with the database and build the object itself before returning it to the Cache API.
Next time the same data is requested, we should get a Cache Hit!
Database Update (Put/Patch/Delete)
The API Gateway will route to the Database API directly because we are modifying an entry in the single source of truth!
Once the database has been updated successfully, the Database API will publish a message in the Message Queue. This message contains all the cache keys that have to be invalidated because they are now outdated compared to the data in the database!
The Cache API doesn't have to update the cache entry in this flow. It will happen automatically next time a user requests data and encounters a Cache-Miss!
Database Insert
Similar to the Database Update, however in some cases it is not necessary to invalidate the cache.
This is because there is just a new entry that will be fetched next time a Cache-Miss happens and automatically insert
the new object to the cache!
This new entry never existed in the cache in the first place, so what would we update?
Message Queue - Cache Key Invalidation
The Cache-Sync-Service subscribes to the Message Queue and listens for events of the cache invalidation topic.
Whenever a matching event is published to the queue, this service connects to the Cache API and requests an invalidation of given keys from the message.
The following concepts are important to fully understand the core structure and data flow inside the application.
Most communication comes from the frontend that requests to fetch or manipulate data. However, there are some things that happen asynchronously behind the scene like the cache key invalidation via Message Queue.
This gives you a small peek at everything happening inside the "Magic Box" behind the API Gateway that the frontend doesn't (and shouldn't) know about.
Cache Hit
The most simple and best case scenario when it comes to fetching data! Requests are routed from the frontend through the
API Gateway to the Cache API.
The entire data object is found in the cache and directly returned to the frontend. There is no faster option.
Cache Miss
Same starting point as the previous scenario, however this time there is no data found in the cache! This can happen when new data has recently been created or modified, or a cache entry expired if TTL (Time To Live) is configured.
The Cache API has to request the same data from the Database API now. The Database API then has to communicate with the database and build the object itself before returning it to the Cache API.
Next time the same data is requested, we should get a Cache Hit!
Database Update (Put/Patch/Delete)
The API Gateway will route to the Database API directly because we are modifying an entry in the single source of truth!
Once the database has been updated successfully, the Database API will publish a message in the Message Queue. This message contains all the cache keys that have to be invalidated because they are now outdated compared to the data in the database!
The Cache API doesn't have to update the cache entry in this flow. It will happen automatically next time a user
requests data and encounters a Cache-Miss!
Database Insert
Similar to the Database Update, however in some cases it is not necessary to invalidate the cache.
This is because there is just a new entry that will be fetched next time a Cache-Miss happens and automatically insert
the new object to the cache!
This new entry never existed in the cache in the first place, so what would we update?
Message Queue - Cache Key Invalidation
The Cache-Sync-Service subscribes to the Message Queue and listens for events of the cache invalidation topic.
Whenever a matching event is published to the queue, this service connects to the Cache API and requests an invalidation
of given keys from the message.
Application Flow
The following concepts are important to fully understand the core structure and data flow inside the application.
Most communication comes from the frontend that requests to fetch or manipulate data. However, there are some things that happen asynchronously behind the scene like the cache key invalidation via Message Queue.
This gives you a small peek at everything happening inside the "Magic Box" behind the API Gateway that the frontend doesn't (and shouldn't) know about.
Cache Hit
The most simple and best case scenario when it comes to fetching data! Requests are routed from the frontend through the
API Gateway to the Cache API.
The entire data object is found in the cache and directly returned to the frontend. There is no faster option.
Cache Miss
Same starting point as the previous scenario, however this time there is no data found in the cache! This can happen when new data has recently been created or modified, or a cache entry expired if TTL (Time To Live) is configured.
The Cache API has to request the same data from the Database API now. The Database API then has to communicate with the database and build the object itself before returning it to the Cache API.
Next time the same data is requested, we should get a Cache Hit!
Database Update (Put/Patch/Delete)
The API Gateway will route to the Database API directly because we are modifying an entry in the single source of truth!
Once the database has been updated successfully, the Database API will publish a message in the Message Queue. This message contains all the cache keys that have to be invalidated because they are now outdated compared to the data in the database!
The Cache API doesn't have to update the cache entry in this flow. It will happen automatically next time a user requests data and encounters a Cache-Miss!
Database Insert
Similar to the Database Update, however in some cases it is not necessary to invalidate the cache.
This is because there is just a new entry that will be fetched next time a Cache-Miss happens and automatically insert
the new object to the cache!
This new entry never existed in the cache in the first place, so what would we update?
Message Queue - Cache Key Invalidation
The Cache-Sync-Service subscribes to the Message Queue and listens for events of the cache invalidation topic.
Whenever a matching event is published to the queue, this service connects to the Cache API and requests an invalidation of given keys from the message.
The following concepts are important to fully understand the core structure and data flow inside the application.
Most communication comes from the frontend that requests to fetch or manipulate data. However, there are some things that happen asynchronously behind the scene like the cache key invalidation via Message Queue.
This gives you a small peek at everything happening inside the "Magic Box" behind the API Gateway that the frontend doesn't (and shouldn't) know about.
Cache Hit
The most simple and best case scenario when it comes to fetching data! Requests are routed from the frontend through the
API Gateway to the Cache API.
The entire data object is found in the cache and directly returned to the frontend. There is no faster option.
Cache Miss
Same starting point as the previous scenario, however this time there is no data found in the cache! This can happen when new data has recently been created or modified, or a cache entry expired if TTL (Time To Live) is configured.
The Cache API has to request the same data from the Database API now. The Database API then has to communicate with the database and build the object itself before returning it to the Cache API.
Next time the same data is requested, we should get a Cache Hit!
Database Update (Put/Patch/Delete)
The API Gateway will route to the Database API directly because we are modifying an entry in the single source of truth!
Once the database has been updated successfully, the Database API will publish a message in the Message Queue. This message contains all the cache keys that have to be invalidated because they are now outdated compared to the data in the database!
The Cache API doesn't have to update the cache entry in this flow. It will happen automatically next time a user
requests data and encounters a Cache-Miss!
Database Insert
Similar to the Database Update, however in some cases it is not necessary to invalidate the cache.
This is because there is just a new entry that will be fetched next time a Cache-Miss happens and automatically insert
the new object to the cache!
This new entry never existed in the cache in the first place, so what would we update?
Message Queue - Cache Key Invalidation
The Cache-Sync-Service subscribes to the Message Queue and listens for events of the cache invalidation topic.
Whenever a matching event is published to the queue, this service connects to the Cache API and requests an invalidation
of given keys from the message.
Application Flow
The following concepts are important to fully understand the core structure and data flow inside the application.
Most communication comes from the frontend that requests to fetch or manipulate data. However, there are some things that happen asynchronously behind the scene like the cache key invalidation via Message Queue.
This gives you a small peek at everything happening inside the "Magic Box" behind the API Gateway that the frontend doesn't (and shouldn't) know about.
Cache Hit
The most simple and best case scenario when it comes to fetching data! Requests are routed from the frontend through the
API Gateway to the Cache API.
The entire data object is found in the cache and directly returned to the frontend. There is no faster option.
Cache Miss
Same starting point as the previous scenario, however this time there is no data found in the cache! This can happen when new data has recently been created or modified, or a cache entry expired if TTL (Time To Live) is configured.
The Cache API has to request the same data from the Database API now. The Database API then has to communicate with the database and build the object itself before returning it to the Cache API.
Next time the same data is requested, we should get a Cache Hit!
Database Update (Put/Patch/Delete)
The API Gateway will route to the Database API directly because we are modifying an entry in the single source of truth!
Once the database has been updated successfully, the Database API will publish a message in the Message Queue. This message contains all the cache keys that have to be invalidated because they are now outdated compared to the data in the database!
The Cache API doesn't have to update the cache entry in this flow. It will happen automatically next time a user requests data and encounters a Cache-Miss!
Database Insert
Similar to the Database Update, however in some cases it is not necessary to invalidate the cache.
This is because there is just a new entry that will be fetched next time a Cache-Miss happens and automatically insert
the new object to the cache!
This new entry never existed in the cache in the first place, so what would we update?
Message Queue - Cache Key Invalidation
The Cache-Sync-Service subscribes to the Message Queue and listens for events of the cache invalidation topic.
Whenever a matching event is published to the queue, this service connects to the Cache API and requests an invalidation of given keys from the message.
The following concepts are important to fully understand the core structure and data flow inside the application.
Most communication comes from the frontend that requests to fetch or manipulate data. However, there are some things that happen asynchronously behind the scene like the cache key invalidation via Message Queue.
This gives you a small peek at everything happening inside the "Magic Box" behind the API Gateway that the frontend doesn't (and shouldn't) know about.
Cache Hit
The most simple and best case scenario when it comes to fetching data! Requests are routed from the frontend through the
API Gateway to the Cache API.
The entire data object is found in the cache and directly returned to the frontend. There is no faster option.
Cache Miss
Same starting point as the previous scenario, however this time there is no data found in the cache! This can happen when new data has recently been created or modified, or a cache entry expired if TTL (Time To Live) is configured.
The Cache API has to request the same data from the Database API now. The Database API then has to communicate with the database and build the object itself before returning it to the Cache API.
Next time the same data is requested, we should get a Cache Hit!
Database Update (Put/Patch/Delete)
The API Gateway will route to the Database API directly because we are modifying an entry in the single source of truth!
Once the database has been updated successfully, the Database API will publish a message in the Message Queue. This message contains all the cache keys that have to be invalidated because they are now outdated compared to the data in the database!
The Cache API doesn't have to update the cache entry in this flow. It will happen automatically next time a user
requests data and encounters a Cache-Miss!
Database Insert
Similar to the Database Update, however in some cases it is not necessary to invalidate the cache.
This is because there is just a new entry that will be fetched next time a Cache-Miss happens and automatically insert
the new object to the cache!
This new entry never existed in the cache in the first place, so what would we update?
Message Queue - Cache Key Invalidation
The Cache-Sync-Service subscribes to the Message Queue and listens for events of the cache invalidation topic.
Whenever a matching event is published to the queue, this service connects to the Cache API and requests an invalidation
of given keys from the message.