How I protect the project from chaos, duplicates and chance

The most unpleasant thing in projects like this isn’t errors but quiet accumulating chaos.

When the same event arrives twice. When media is saved again. When the system gradually starts contradicting itself.

From the outside it’s almost invisible. But this is exactly how a project loses its shape.

The first thing I had to do was stop duplicates at the lowest level:

UNIQUE(chat_id, msg_id, media_type)

The database simply won’t let the same thing be written twice. No extra logic and no hope that someone will sort it out by hand later.

Then comes the second layer:

INSERT OR IGNORE INTO ann_message_media

If the event has already happened, it just doesn’t go any further. No extra state is created.

But duplicates are only part of the problem.

There’s another form of chaos: repeated actions. When the system replies once too often, publishes once too often, or starts again something that no longer needs starting.

Here comes:

cooldown_until

The system stores the moment before which it must do nothing. This is no longer about functionality but about discipline of behaviour.

The next principle concerns heavy operations. They can’t be performed right at the moment of a reply. If you recalculate the profile for every line, the system becomes overly sensitive and starts making noise.

So part of the logic is moved to the background: queues, deferred updates, accumulating material before acting.

And finally, failures.

If an external layer goes down, the project shouldn’t turn into either silence or garbage. So there are pauses, fallback scenarios and state recovery here, and the database works through WAL so that writing doesn’t block the whole system.

In the end, protection is built in layers:

• the database doesn’t let duplicates in
• the code doesn’t amplify repetition
• cooldown holds back excess activity
• heavy logic is moved out of the dialogue
• a failure doesn’t destroy the whole flow of work

And only after that can you talk about the quality of replies at all.