Update docs for lb workers with deduplication

doc/development/sidekiq/idempotent_jobs.md

@@ -185,30 +185,6 @@ end
 Duplicate jobs can happen when the TTL is reached, so make sure you lower this only for jobs
 that can tolerate some duplication.
 
-## Deduplication with load balancing
-
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6763) in GitLab 14.4.
-
-Jobs that declare either `:sticky` or `:delayed` data consistency
-are eligible for database load-balancing.
-In both cases, jobs are [scheduled in the future](#scheduling-jobs-in-the-future) with a short delay (1 second).
-This minimizes the chance of replication lag after a write.
-
-If you really want to deduplicate jobs eligible for load balancing,
-specify `including_scheduled: true` argument when defining deduplication strategy:
-
-```ruby
-class DelayedIdempotentWorker
-  include ApplicationWorker
-  data_consistency :delayed
-
-  deduplicate :until_executing, including_scheduled: true
-  idempotent!
-
-  # ...
-end
-```
-
 ### Preserve the latest WAL location for idempotent jobs
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69372) in GitLab 14.3.

doc/development/sidekiq/worker_attributes.md

@@ -259,10 +259,11 @@ these scenarios, since `:always` should be considered the exception, not the rul
 To allow for reads to be served from replicas, we added two additional consistency modes: `:sticky` and `:delayed`.
 
 When you declare either `:sticky` or `:delayed` consistency, workers become eligible for database
-load-balancing. In both cases, jobs are enqueued with a short delay.
-This minimizes the likelihood of replication lag after a write.
+load-balancing. 
 
-The difference is in what happens when there is replication lag after the delay: `sticky` workers
+In both cases, if the replica is not up-to-date and the time from scheduling the job was less than the minimum delay interval,
+ the jobs sleep up to the minimum delay interval (0.8 seconds). This gives the replication process time to finish.
+The difference is in what happens when there is still replication lag after the delay: `sticky` workers
 switch over to the primary right away, whereas `delayed` workers fail fast and are retried once.
 If they still encounter replication lag, they also switch to the primary instead.
 **If your worker never performs any writes, it is strongly advised to apply one of these consistency settings,