Question: I am using solr 4.10 setup on a **3 node cluster(solrcloud)** with zookeeper and **RF = 1.** Total 3 shards. 

The problem here is 2 phase. 
1. I added **50 million** records into the index which has a uuid field(**user\_id**) as a unique key. The uuid field was generated by the application and not solr. The records were indexed in batches of 5k and committed. After indexing i saw there were a lot of duplicates in the index. Even though uuid was specified as a unique key. **Somehow 2 different shards had the same document.** 

When i tried to return the counts for a particular query, the shards returned the counts including duplicates. It returned **numFound=60,686** .
But when i tried to retrieve all the 60,686 records **it returned only 52,760** which was the actual records expected. 

2. It looked like there were 7926 duplicates, **but there were only 74 duplicates** when i checked

select?q=tag%3A123&rows=0&wt=json&indent=true&facet=true&facet.field=user\_id&facet.mincount=2

i manually deleted the duplicates and the count went down to 60538 which is still wrong.
I see each shard is contributing to this false count when i turned on debugQuery. 

Is there a facet cache or something that needs to be cleared ? what are these remaining extra counts ? My application is count dependent so this is a big issue i'm facing. 

Thanks in advance.

Answer: 
The problem seemed to be with the document router. By default solr uses "implicit" router, i changed it to "compositeId" and a document was always sent to the same shard.

Ref: <https://lucidworks.com/blog/2013/06/13/solr-cloud-document-routing/>
If you had deleted or updated any records, they are still contributing to the facet counts until Solr does automatic merge or you do manual optimize trigger (very expensive).

That's the price of the fact that Lucene does not actually allow deleting documents in place, so it is marked gone at the higher level. Those documents never show up in the search, but they do contribute to the counts.

So, if this is a test system, try *optimize* call and see if your problem goes away. But this may not be a solution for production, just a way to confirm the hypothesis.