---
title: "Comment by Kartik N V J K on \"Deleting Personal Data from a RAG System in .NET\" | Hashnode"
description: "The overnight-retry rewriting the deleted record is the part I see most teams miss: deletion gets treated as a single event, not something that has to hold agai"
url: "https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6abead08656b10339d06ec14"
---

[Discussion](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943)

Comment [Deleting Personal Data from a RAG System in .NET](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943)

[Kartik N V J K](https://hashnode.com/@kartik-nvj)

[Oct 1](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6abead08656b10339d06ec14)

The overnight-retry rewriting the deleted record is the part I see most teams miss: deletion gets treated as a single event, not something that has to hold against every async job that can re-ingest. Building lineage at ingest instead of similarity-searching the vector store for a name later is the right call, since that search never catches all the derived chunks. How do you handle a record that is mid-ingestion when the erasure request lands?

[Patrick Kearns](https://hashnode.com/@fullstackcity)

[Oct 2](https://hashnode.com/posts/deleting-personal-data-from-a-rag-system-in-net/6abd5fa1c02e2338b2100943/comment/6abead08656b10339d06ec14#reply-6abf51b499ee0b1509bbfc38)

I think the ingestion would need to be Atomic really. I'd mark the subject as blocked before starting the purge, then have ingestion workers check that marker before processing and again when committing each derived write. Then the final check needs to be atomic with the write where possible otherwise, deletion can land between the check and the insert.