I’m starting a project using .NET and Microsoft Orleans, running on Kubernetes. The main reason I chose Orleans is that I have a system that deals with accounts. There can be millions of accounts, but only thousands will be active at any given time, with occasional peaks of tens of thousands. I need the system to scale during these peaks. I also need to ensure that only one operation can be performed on an account at a time to avoid concurrency issues.

In my system, there is only one type of Grain, called AccountGrain, which represents accounts and handles all operations that can be performed on them. This Grain has a private attribute with a list of objects that represent the account’s state as a cache. Most operations use this cache (LINQ queries, adding objects, etc.), so performance is critical.

Most operations in this system work with accounts, even though they belong to different “domains.” For example, I have a “Purchases” domain, an “Contract Status” domain, and a few others. Each domain has a library with its own REST API, but they all end up calling the AccountGrain. I’m concerned that the AccountGrain will end up with a huge number of functions from all these domains, making it unmanageable, violating the Single Responsibility Principle, and having too many lines of code.

I would like to separate these functions by domain or functionality group, ideally each in its own library (module), while still maintaining access to the cached state in the grain, access to timers/reminders, with the concurrency management of Orleans, etc. Being able to call other modules is a must (e.g., in the example below the Purchase method needs to call the Contract State module to create a contract, and then store the result in the grain’s cache).

I tried to move grain’s logic to classes and inject these classes into the grain. The problem with this approach is that I loose access to the grain. Sure I can pass the state as a parameter, but I loose access to timers, reminders, state management (read/write), and other functionalities implemented in Orleans’ “Grain” base class.

I also though on creatin an interface wrapping these functionalities, but then I would need to create “Public methods”, and calling these public methods from the grain itself are going to cause deadlocks.

Example:

public class AccountGrain : Grain
{
    // This is like a “cache” because most methods need to know the products an account has 
    private List<PurchasedProduct> _purchasedProductsCache { get; }

    // This is like a “cache” because most methods need to know the contracts an account has 
    private List<Contract> _activeContractsCache { get; }


    // This a very simplified example of the “purchasing” domain actions
    #region Purchasing Domain

    public Task Purchase(int productId)
    {
        // Do actions
        // Create a contract for the purchase (calling CreateContract(); see next methods) and update _purchasedProductsCache 
    }
    public Task CancelPurchase(int purchaseId) {
        // Do actions
        // Update _purchasedProductsCache and cancel a contract for the purchase (calling CreateContract(); see next methods)
    }

    #endregion


    // This a very simplified example of the “card processing” domain actions
    #region Card Processing Domain

    public Task ProcessCardTap(int cardId)
    {
        // Do actions
        // Some of these actions can be calling Purchase, CreateContract, etc.
    }

    public Task ProcessDelayedCardTap(int cardId) 
    {
        // Do actions
        // Some of these actions can be calling Purchase, CreateContract, etc.
    }

    #endregion

    // This a very simplified example of the “contract management” domain actions
    #region Contract Management
    
    public Task CreateContract(CreateContractRequest request)
    {
        // Do actions
        // Add new contract to _activeContractsCache
    }

    public Task CancelContract(int contractId)
    {
        // Do actions
        // Delete contract from _activeContractsCache
    }

    #endregion
}

Note: I originally asked this on StackOverflow, but it was suggested that this platform might be more appropriate.