assume that a combination of our two approaches might be sufficient even for time of high traffic & loads.

It really depends upon how you combine them :)

What I can say is that your current code that starts two threads every second with one of them making a new connection to a database each time and the other freezing and thawing a compound structure to and from a shared hash is not going to run quickly.

Perl's threads are quite different from the kind threads found in say Java or Ruby where this kind of "spawn a thread, do a little and throw it away" coding style is common. and practical. Even there, creating new connections to MySql at the rate of one per second and then abandoning them is very likely to consume (leak) resources both in the DBI layers and at the MySQL server end.

I seem to recall that (at v3.xomething), MySQL would not reuse a dropped connection for something like 15 minutes or so? This may have been fixed or be configurable or I may have remembered it wrong, but in any event it is a far from ideal strategy if you are hoping to handle high data rates.

Using a single, long running thread that makes the connection to the DB when it starts and then reuses the handle to issue queries is a much better idea. Without seeing where, how and when your event_handler routine is called; and what SOD::EventCooker is; and what is populating your 'event' table, it is quite hard to advise further.

A high level pseudo-code description of your app might allow us to advise further.