To me, this seems like you need to take a step back and think about each step and figure out what you're trying to do. It sounds like you really have three or four systems you're trying to implement at once. You have a message queue (actions), message logging, notifications, and possibly some user-level interactions with these systems (beyond simply displaying a notification to the user in reaction to an event).
The message queue itself is probably the simplest step, and the one you're probably the closest to having complete. The hardest part about implementing a message queue is usually keeping everything else separate. You should think about what information you really need in the message queue, and what isn't really relevant. Usually you just need the message (action) and some metadata (common metadata might be a message type/category, date/time the message was inserted, time to live/expiration, a delay value to prevent the queue from processing the message until a certain amount of time has passed since insertion, and an ID to aid in managing the queue).
A basic queue would just be a simple CRUD system. You can create, read, update, and delete messages as you see fit.
A slightly more complicated system to implement, but significantly more powerful to use, would be a pub/sub system, where any code can publish a message, and code subscribes to receive certain types of messages. When the queue is processed (maybe you process it on every visit, in response to certain events, manually from a control panel, or via the CLI so the system can trigger it from a cron job), each message is sent to all of the subscribers to handle as they see fit, then removed from the queue.
In the pub/sub system, if you want your message logger to log every message that goes through the system, you make it a subscriber to all of the message types. If you want notifications for certain types of messages, you make the notification system a subscriber to those message types.
Your notification system might even insert new messages into the queue which are only processed when the specific user who is intended to see those notifications logs in. In that case, you may want messages removed from the queue only when they are processed by subscribers, and you would not subscribe your message logger to these types of events. Alternatively, you could setup your queue system to allow multiple queues, and give each user their own notification queue which is processed when that user logs in (or maybe you allow the user to set a time for a daily or weekly notification and send their notifications in a batch via email).
One more complication I might add to this system would be to encapsulate the storage of the messages so you could change it out in the future. You may find the database is not the ideal way to store a message queue. You might decide to move your queue to Redis, Memcached, a NoSQL database, or a cloud-based message queue. Maybe you don't have access to any of these options now, or you don't want to throw out the work you've done on the database interaction, but you should isolate that code from the rest of the message queue code so you can replace it, even if it's just to try some of the alternatives in development/test environments to see if they would improve performance enough to be worth investing in a different hosting option for your production environment.
