2

I'm using StackExchange.Redis library, it seems perfect.

Hard-coded events related BankAccount with ID 1:

// UNSORTED COLLECTION
public static List<Event> DomainEvents = new List<Event>()
    {
        new Event() { Data = @"{ 'Operation': 'WithdrawalPerformed', 'Amount': '10', 'UtcDateTime': '05/18/2019 18:47:41.084' }" },
        new Event() { Data = @"{ 'Operation': 'DepositPerformed', 'Amount': '3.75', 'UtcDateTime': '05/15/2019 19:48:51.099' }" },
        new Event() { Data = @"{ 'Operation': 'AccountCreated', 'CustomerId': '56', 'Balance': '0', 'UtcDateTime': '05/01/2019 11:30:00.084' }" },
        new Event() { Data = @"{ 'Operation': 'OwnerChanged', 'CustomerId': '7993', 'UtcDateTime': '05/25/2019 10:00:00.084' }" },
        new Event() { Data = @"{ 'Operation': 'DepositPerformed', 'Amount': '33.6', 'UtcDateTime': '05/20/2019 18:47:41.084' }" },
    };

When I transfer them to Redis, I create a LIST with the name that holds ID of the entity - BankAccount_1:

foreach (var item in DomainEvents)
{
    db.ListLeftPush(listName, item.Data); // listName = "BankAccount_1"
}

Is this a good approach?

My main concern is that I may end up with too many lists.

In this case we have a list per Account record.

So, if there's a million of Account records in my SQL Server DB - Redis will have as many lists.

To me it seems like it's the best we can do in terms of performance. The data is perfectly separated. E.g. when we need to fetch events for Bank Account with ID 665 - the query is simple and straightforward:

var events = db.ListRange("BankAccount_665", 0, -1);

IMHO, if we keep all the events in one List / HashSet - it's going to be impossible to FILTER them properly. Because the data is in JSON format. We'll have to fetch extremely huge amount of data which needs filtering. It's a depletion of CPU resources & RAM.

What are your thoughts?

Also, do you think it'd be beneficial to back up events in SQL Server?

I think of the following schema:

| ID | AggregateType | AggregateID | JsonData |

  • Correct me if I'm wrong but I think it's not the best idea to keep valuable information inside an in-memory database. I would be more comfortable with a DB which eventually would persist data to the disk. SQL DB IMO would be more preferable as it believed to be more suitable for analytic queries. – Bohdan Stupak May 30 at 8:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.