I am developing a service that relies on users being able to recieve messages that they themselves choose. These messages need to be stored somewhere before they are send for processing.
Right now I'm storing them in a postgres database, but I have a feeling it doesn't scale well.
The current layout is:
ID - MESSAGE - DATE - TIME
The DATE and TIME field holds the time and date for when the message should be send for processing. This doesn't scale well, as if a message needs to be send the first monday every month, it would take up 12x as much space.
Problem is that I can't seem to find another way to represent when a message should be send for processing? Ideally I'd love to be able to represent each and every date in a single row.
We were also disucssing using Redis, but quickly decided not too, as we would need the database for the webfrontend.
Anyone have any idea how to optimize the message storage? How to represent when a message should be send for processing?
I am also open for any other suggestions on how to tackle this.