Which change should the developer make to the application to meet these requirements?
Modify the application to use a lazy loading caching strategy with a small TTL value.
Modify the application to use a write-behind caching strategy.
Modify the application to use a write-through caching strategy.
Modify the application to use a lazy loading caching strategy with a large TTL value.
Explanations:
A lazy loading caching strategy with a small TTL value may not be optimal for this scenario, as frequent database reads of the same postal codes could lead to excessive cache misses and increased latency. This approach does not leverage the predictable nature of the read-heavy workload.
A write-behind caching strategy is not suitable here since the application performs more reads than writes. This strategy focuses on deferring writes to the database, which could lead to data inconsistency and does not address the need for improving read performance.
A write-through caching strategy ensures that data is written to the cache and database simultaneously, which is beneficial for write-heavy applications. However, since this application is read-heavy, this strategy does not optimize read performance and can add unnecessary write overhead.
A lazy loading caching strategy with a large TTL value is appropriate because it allows frequently accessed postal code data to be cached for a longer duration. This reduces the number of database reads significantly, improving overall application performance and decreasing latency.