[README] info about no storage backend

README.md

@@ -455,3 +455,27 @@ If you want to add a new job, just add a new constructor to `Job`
 (with all the arguments this job needs), implement to/from JSON
 serialization (so we can send and read that job via the broker) and
 implement appropriate handler in `G.C.Worker` -> `performAction`.
+
+## No storage backend
+
+When you compare `haskell-bee` with the [celery
+project](https://docs.celeryq.dev/en/stable/), you can notice 2
+things:
+- both have configurable brokers
+- `haskell-bee` doesn't have a storage backend This is because, when
+analyzing our tasks, we actually don't store any **task** results
+anywhere. The progress can be reported immediately via notifications,
+same for errors. And when a task is executed (e.g. add to corpus with
+query), the garg db state is mutated.
+
+One could discuss if such a **task** storage backend is needed: if you
+want to debug some task, just run the worker and log its results. You
+can inspect later the errors in the log. On the other hand, if we had
+a production worker, which processes lots of tasks, it could be a pain
+to store the results of all of them, as we mostly don't care about the
+finished ones.
+
+Also, the `haskell-bee` framework allows to add custom hooks to the
+worker. In particular, search for `onJobError`/`onJobTimeout` in
+`Worker.State`. We could trigger some `IO` action on these hooks
+(logging, sending mail, firing rockets).