Delete discussion technical specification

Synopsis

delete discussion

API receive a DELETE /discussions/ HTTP request.

API is not responsible of the business logic, it only handle a message and call an object that will execute the logic (a core object).

The core object will retrieve all messages that belong to the given discussion_id (core method filter(...) can do that). For each retrieved message, Message.date_delete is set to now() (UTC timezone) adn then message saved. The core method Message.save() will propagate changes on cassandra and elasticsearch.

The Discussion.date_delete parameter is set to same date as message.

So our objects (message and discussion) are not really deleted from our storages services, they are only flagged as it with a timestamp information. All interfaces to retrieve these objects filter automatically with a date_delete = NULL.

This is called a soft delete principle. Objects will be really deleted later (many days or months later) by a dedicated process.

The API return an HTTP status 200 if everything is fine.

Things to do

What part of code to consider

An important design note

For an huge discussions the global response time for such DELETE action will take many seconds (at least). The natural evolution for this process will be to run asynchronous and emit a notification to client when it's done.

This is where the message queuing service (nats) is used, to do asynchronous processing.

[..]