Around 25 years ago, I was part of a team that was building a client-server workflow system in C++. We had sharded SQL databases and an object server that manag

Around 25 years ago, I was part of a team that was building a client-server workflow system in C++. We had sharded SQL databases and an object server that managed the ORM for each shard and a queue server that kept a prefetched list of objects for each queue. A central broker handled client applications and communicated with the queue server and the object server and also handled transaction management. Since this was a workflow, objects moved from queue to queue as defined in the buisness process and were acted upon by applications (could be an automated step or user-driven). One of the main techniques we used was a memory manager (using overloaded new/delete operators) and data serialization such that we could build the prefetched set of objects in a memory manager (at the object server) and persist it to disk on a central file server. The client could just load that file into memory and directly access the objects without any parsing. We had a whole object API to encapsulate this. When the client was done with processing, it would just flush the memory to disk (on the network file server) and send a message the broker and the broker/objectserver/queueserver handle the write lazily. Also, if the system crashed, we had a tool to rebuild the object server state and queue server state from the SQL databases, so there was some recovery/resiliency built in. Granted, the operating environment of the client and server was controlled by us and this architectural choice made sense. But, the main thing that surprised me was the performance gained by the client apps not having to parse out the objects due to the use of the memory manager and the reduction of application latency (for users) due to the interleaving of prefetch and lazywrites. This was by no means a simple trick, but certainly very clever.