What is the fastest way to design entity persistence with a database?

I am currently designing an Entity framework using Java and MongoDB. However, the language and database used are not important for my question but I will use them for my examples.

My application is very read heavy and writes do not happen often.

I am looking for the best way to design the persistence system for my entities, my target is to have a very fast read speed while also staying flexible.

An entity is implemented with simple setThing(Thing thing) and Thing getThing() methods on the entity instance.

For example an entity can basically be described with this interface:

public interface MyEntity {

    String getName();

    void setName(String name);

}

---

Characteristics of my application

• there can be multiple instances of the application accessing the same database server, the entity state must be consistent on all application instances
• there are way more reads than writes, that means the performance of reads should be really good.
• read access to the fields of the entity is rather random, some parts of the application only get a single field while others get multiple values.

---

Ideas I considered

• Caching the complete document

  • Read: If the entity document is not currently cached, the whole document will be loaded into the cache and further reads of single values will access the cache, making reads (except the first one) very fast.

  • Write: The application will automatically decide when to write the cached document to the database.

  • Problem: The document in the database is never the current version since only the application knows about the current version in its cache. That means that there can only be a single instance of the application at a time.

• Caching the complete document in a distributed memory system

  • Read: same as the first idea, but the cache is a distributed memory system.

  • Write: same as the first idea, but the cache is a distributed memory system.

  • Problem: Solves the problem of the first idea, but introduces the new problem that there needs to be a system in place which decides which app instance is responsible to read when and what, etc. and also makes development harder since the distributed nature of the cache structure must always be kept in mind.

• No caching, reading and writing directly to the database

  • Read: the field is requested by calling the entity method, the value will be read from the document in the database and returned to the method caller.

  • Write: the value passed to the method will be written into the document in the database.

  • Problem: There needs to be multiple requests if a part of the app wants to access multiple properties which slows everything down since the latency multiplies with the amount of requests.

• No caching, reading and writing directly to the database but using the whole document

  • Read: the field is requested by calling the entity method, the whole document will be read from the database and the selected value returned.

  • Write: the value passed to the method will be written into the document in the database.

  • Problem: Obviously not a good idea since the request is bigger than needed and still does not solve the problem of the single-value idea.

---

What do you think is the bast way to solve this? Do you have any other ideas other than the ones I already had which match the requirements of my application?

Thanks in advance.