Most systems run several
Grown-up systems rarely run one database. The usual shape is a relational store plus a memory cache plus a search engine: truth, hot path, text.
That is fine. What separates a clean version of it from a haunted one is a single rule: one store holds the truth, and everything else holds a copy you could delete and rebuild.
You took something on the moment there were two stores. You now have a synchronising problem, and there is a tempting wrong answer to it.
The tempting wrong answer
The tempting answer is to write twice from your application, first to the database, then to the search engine. Do not ship that. The second write fails sometimes, during a deploy, on a timeout, and the first one does not roll back. The two drift apart in silence, and you find out months later when a seller asks why their product loads fine but never appears in search.
The boring correct answer is different. Your database already writes every change into a log for its own recovery. A tool tails that log and publishes each change onto a stream, and a small consumer applies it to the search engine.
The copy runs milliseconds to seconds behind the truth, and it cannot silently skip a write. If the index gets corrupted you replay the stream and rebuild it. Derived data is a cache with a rebuild button, and the rebuild button is the part you have to actually test before you need it.
Each extra store costs something. Monitoring, upgrades, a new way to fail, another reason to be paged.
And tell people the freshness number before launch rather than after: data appears in search a second after it was written. Two stores is normal, three is common, five is a team that has been saying yes too often.
Worked example
Meera's rental-listings site dual-writes: save the listing to Postgres, then index it in Elasticsearch from the same request handler. During a Tuesday deploy the ES client library starts throwing on a connection pool bug, the handler catches and logs the error, and for nine days roughly 3 percent of new listings never reach the index. Nobody notices until a landlord calls asking why his 14 apartments are invisible in search. The audit finds 4,100 missing listings. The rebuild takes a weekend: Debezium tails the Postgres WAL into Kafka, a small consumer upserts into Elasticsearch, and the in-request indexing code is deleted. She then reindexes all 12 million listings from scratch in five hours to flush remaining drift. The next ES outage costs 40 minutes of indexing lag and zero lost documents.