Searching for Database Operation Pattern

i’m searching for an Akka pattern for database operations. I have an actorsystem with lots of databases and my actors are interacting with them (read, write). For managing the reads and writes, i have two ideas:

  1. Each database has one main actor that is connected to the database and receives the read and write requests from other actors.
  2. Every actor that needs data from this database is connecting on it’s own. So i have several connections to the database (read and write).

The first approach maybe causes data inconsistency and the second idea can create data bottleneck. In addition to that i know, that it’s important which API is behind the database (blocking or non-blocking).

Does somebody know a design pattern or general Rules for this situation?

Thanks for your help!

I don’t know of any widely known pattern, but I would take care to

  • not overflow the database connection pool
  • define a separate dispatcher if you plan to use a blocking driver (akka comes with a default blocking-io configured if you look at the doc for the default .conf file)

This implies that I would avoid solution 2, where you don’t control the load going into the database (1) nor will be easily able to separate the dispatcher used to make the call (2).

The first things that comes to my mind (I suggest you think about alternatives too), would be to use a router actor as database operations gateway, and to configure the size of the workers based on connection pooling available.
They won’t be 1:1 of course but I would consider to keep the number of workers limited to something of the same magnitude.
Also I’d use a dedicated dispatcher for the router.

That said, the exact situation might be best served by other solutions, because the details will always have a significant impact (we’re not even considering which database you’re using, so a general solution won’t make much sense).
Also I’d take the care to prepare a measurement setup and play with the different configuration parameters to fine-tune and verify you’re not creating any bottleneck or deadlock.