DEV Community: Ivan Pavlov

Discriminated unions in C#

Ivan Pavlov — Mon, 20 Oct 2025 23:04:57 +0000

Intro

This small article is about algebraic data types and their surrogates in C#.

What does this term mean?

The term algebraic data type is from the functional paradigm.
In the .NET ecosystem, it is presented by the F# language and called Discriminated unions.
Besides F#, this type is also present in Scala, Haskell, and other functional languages.
Also, many OOP languages adopt DU.
For example, Kotlin has sealed classes, and Java has sealed interfaces.

What about C#? It still does not have its implementation, but the development finally started after several years of moving the proposal to the next year.
Until the new feature is in development .NET community invented several ways to emulate discriminated unions behavior.

What is it about?

If the term discriminated unions is new to you, it would be easy to read the article on Microsoft Learn F# documentation Discriminated Unions.
I would like to explain it in a short description - a type that may be presented by different variants, but only one at a time.
It is like C# enum with fields or one layer of inheritance in C#, but it combines all variants in one place.

Let's start with an example and F# - we need to create a bank account and process a payment for a bank account.
Today, an international bank account might be presented in different systems, for example, IBAN and SWIFT.

type BankAccountCommonData = { Title: string; BankName: string; BankAddress: string }

type BankAccount =
    | Iban of common: BankAccountCommonData * Number: string
    | Swift of common: BankAccountCommonData * Code: string
    // Uncomment this line to get an warring
    // | Routing of common: BankAccountCommonData * Routing: string

type BankAccountServiceDu =
    static member CreateBankAccount(): BankAccount =
        let number = ""
        let commonData = { Title = ""; BankName = ""; BankAddress = "" }
        Iban(commonData, number)

    static member ProcessPayment (payment: string, account: BankAccount) : string =
        let ProcessIban (payment: string, accountData: BankAccountCommonData, iban: string) =
            // Logic here
            String.Empty

        let ProcessSwift (payment: string, accountData: BankAccountCommonData, swift: string) =
            // Logic here
            String.Empty

        match account with
        | Iban(common, number) -> ProcessIban(payment, common, number)
        | Swift(common, code) -> ProcessSwift(payment, common, code)

This F# code shows a Warning - Warning FS0025 : Incomplete pattern matches on this expression, which indicates that not all cases are covered by switch.
That warning can be transformed into an error and block the application from compiling, rather than forcing developers to address an issue with switch.

Why do we need it?

This answer is simple - to present branched logic or data.
The most native way for C# is inheritance. The same example from F# is presented in a traditional C# inheritance:

internal abstract record BankAccountBase
{
    public required string Title { get; init; }
    public required string BankName { get; init; }
    public required string BankAddress { get; init; }
}

internal sealed record IbanBankAccount(string Number) : BankAccountBase;

internal sealed record SwiftBankAccount(string Code) : BankAccountBase;

internal static class BankAccountServiceInheritance
{
    internal static BankAccountBase GetBankAccount()
    {
        // Logic here

        return new IbanBankAccount("123")
        {
            Title = "T",
            BankName = "A bank",
            BankAddress = "An address"
        };
    }

    internal static void ProcessedPayment(string payment, BankAccountBase bankAccount)
    {
        string ProcessIban(IbanBankAccount iban, string paymentInfo)
        {
            // Logic here
            return string.Empty;
        }

        string ProcessSwift(SwiftBankAccount iban, string paymentInfo)
        {
            // Logic here
            return string.Empty;
        }

        var result = bankAccount switch
        {
            IbanBankAccount iban => ProcessIban(iban, payment),
            SwiftBankAccount swift => ProcessSwift(swift, payment),
            _ => throw new ArgumentOutOfRangeException(nameof(bankAccount), typeof(BankAccount).ToString(), null)
        };

        // Logic here
    }
}

"What do we need to improve over there? It looks good!" you may say, but I have to tell you that DU has one necessary part - it is exhaustive switch.
F#, Scala, Haskell, Rust, Java, Kotlin, and even Dart have their implementation of algebraic data types coupled with exhaustive switch.
What does "exhaustive" mean? It is switch that requires covering all possible variants of the variable with a finite set.
Usually in C# code, we reach exhaustiveness with a default arm, which returns a default value or throws an Exception, like in the example above.
In a case, if someone decides to add a new variant of a bank account, for example, with a Routing number for the UK, and forgets to add this variant to the switch in the ProcessedPayment method, the code will compile, and the application will throw ArgumentOutOfRangeException instead of processing a payment with a bank account based on the Routing Number.
With DU and exhaustive switch, we can prevent this issue and avoid a bag.

C# DU

We can get something like an exhaustive switch using out-of-the-box functionality just using a record (class or struct) that combines all branches as nullable properties, and utilize the record's deconstruct method in switch expression.

Look at the ProcessedPaymentExhaustive method below; it does not look pretty, and readability is not great, but it works because the generated deconstruct method includes all properties by default, and the code will not compile if pattern matching does not cover all variables in the tuple.

internal abstract record BankAccountBase
{
    public required string Title { get; init; }
    public required string BankName { get; init; }
    public required string BankAddress { get; init; }
}

internal sealed record IbanBankAccount(string Number) : BankAccountBase;

internal sealed record SwiftBankAccount(string Code) : BankAccountBase;

internal readonly record struct BankCreateResultTuples(BankAccount.Iban? Iban, BankAccount.Swift? Swift);

internal static class BankAccountServiceRecord
{
    internal static BankCreateResultTuples GetBankAccount()
    {
        // Logic here

        return new BankCreateResultTuples(
            null,
            new BankAccount.Swift("123")
            {
                Title = "T",
                BankName = "A bank",
                BankAddress = "An address"
            }
        );
    }

    /// <summary>
    /// Non-exhaustive switch
    /// </summary>
    internal static void ProcessedPayment(BankCreateResultTuples bankAccount)
    {
        var result = bankAccount switch
        {
            { Iban: null, Swift: not null } => "",
            { Iban: not null, Swift: null } => "",
            _ => throw new ArgumentOutOfRangeException(nameof(bankAccount), bankAccount, null)
        };

        // Logic here
    }

    /// <summary>
    /// Has some exhaustiveness
    /// </summary>
    internal static void ProcessedPaymentExhaustive(BankCreateResultTuples bankAccount)
    {
        var result = bankAccount switch
        {
            (null, not null) => "",
            (not null, null) => "",
            _ => throw new ArgumentOutOfRangeException(nameof(bankAccount), bankAccount, null)
        };

        // Logic here
    }
}

OneOf

The most well-known surrogate of DU in C# is the OneOf library.

internal readonly record struct BankAccountCommonData(string Title, string BankName, string BankAddress);

/// <summary>
/// A first variant of DU
/// </summary>
internal readonly record struct Iban(string Number, BankAccountCommonData CommonData);

/// <summary>
/// A first variant of DU
/// </summary>
internal readonly record struct Swift(string Code, BankAccountCommonData CommonData);

/// <summary>
/// A possible third variant of DU (not in use)
/// </summary>
internal readonly record struct Routing(string Route, BankAccountCommonData CommonData);

internal static class BankAccountServiceOneOf
{
    /// <summary>
    /// Return a DU that is presented by <see cref="OneOf{T0, T1}"/>
    /// </summary>
    internal static OneOf<Iban, Swift> GetBankAccount()
    {
        // Logic here

        var commonData = new BankAccountCommonData("Title", "A bank", "An address");
        return new Iban("Number", commonData);
    }

    /// <summary>
    /// Consume a DU that is presented by <see cref="OneOf{T0, T1}"/>
    /// Add a third generic to the account argument type to get a compiler error.
    /// </summary>
    internal static void ProcessPayment(string payment, OneOf<Iban, Swift> account)
    {
        var result = account.Match(
            iban => ProcessIban(iban, payment),
            swift => ProcessSwift(swift, payment)
        );

        string ProcessIban(Iban iban, string paymentInfo)
        {
            // Logic here
            return string.Empty;
        }

        string ProcessSwift(Swift iban, string paymentInfo)
        {
            // Logic here
            return string.Empty;
        }
    }
}

It emulates discriminated union behavior using hardcoded generic parameters and overloading types.
It has several modes - we can use a generic type or create our own type and reuse it, but in this case, it should be a class.
OneOf is a wrapper around returning type, it is struct, and allows using class or struct as a generic parameter, which is useful if you are concerned about memory consumption and heap allocations.
To utilize exhaustiveness, we must use the Match method and set for each variant a method for processing this variant.
If someone added a new variant to the method signature, then another overload of OneOf will be used, and the code will not compile until all variants in the Match method are covered.

The big disadvantages of the library are method signature in asynchronous code - a returning type may be enormous, up to 100 characters, also it requires wrapping all synchronous OneOf returns in Task in the Match method.
Another thing that someone may find inconvenient is that OneOf allows to use of up to 8 variants, but in this case, it would be better to review the logic and entities.
PS: It is similar for Choice type in F# (but this type is a DU under the hood).

StaticCs | static-cs

The library static-cs makes the switch exhaustive!

[Closed]
internal abstract record BankAccount
{
    private BankAccount()
    {
    }

    public required string Title { get; init; }
    public required string BankName { get; init; }
    public required string BankAddress { get; init; }

    internal sealed record Iban(string Number) : BankAccount;

    internal sealed record Swift(string Code) : BankAccount;

    // Uncomment this line to get Error CS8509 during compilation.
    // internal sealed record Wire(string Code) : BankAccount;
}

internal static class BankAccountServiceStaticSc
{
    internal static BankAccount GetBankAccount()
    {
        return new BankAccount.Iban("Number")
        {
            Title = "T",
            BankName = "A bank",
            BankAddress = "An address"
        };
    }

    internal static void ProcessPayment(string payment, BankAccount account)
    {
        var result = account switch
        {
            BankAccount.Iban iban => ProcessIban(iban, payment),
            BankAccount.Swift swift => ProcessSwift(swift, payment),
        };

        string ProcessIban(BankAccount.Iban iban, string paymentInfo)
        {
            // Logic here
            return string.Empty;
        }

        string ProcessSwift(BankAccount.Swift iban, string paymentInfo)
        {
            // Logic here
            return string.Empty;
        }
    }
}

It is very easy to use because it uses Roslyn analyzer and brings only one new thing to code - the attribute Closed, anything else is out of the box C# features.
To use a DU and make the switch exhaustive, we should create a base abstract class or record, make the default constructor private, put all derivatives inside the class, and mark it with the attribute Closed.
One necessary detail - do NOT use any default arm in switch anymore!
An additional very useful thing is to make the warning CS8509 as Error to prevent the code from building if not all cases are covered by switch.
So the same example - someone added a new variant of a bank account (with a Routing number for the UK), and forgot to add this variant to the switch in the ProcessedPayment method.
Now the code will NOT compile, the builder shows the error in the console, and a developer is forced to add methods to process all derivatives of the base class.

There are other libraries to emulate DU behavior, but I prefer this way because it has fewer external dependencies and looks more C# native.

PS: Looks familiar?) This construction is very close to Kotlin sealed classes.

sealed class BankAccount {
    abstract val title: String
    abstract val bankName: String
    abstract val bankAddress: String

    data class Iban(
        val number: String,
        override val title: String,
        override val bankName: String,
        override val bankAddress: String
    ) : BankAccount()

    data class Swift(
        val code: String,
        override val title: String,
        override val bankName: String,
        override val bankAddress: String
    ) : BankAccount()
}

fun createPayment(): BankAccount {
    // Logic here
    return BankAccount.Iban(number = "Number", title = "Title", bankName = "A bank", bankAddress = "An address")
}

fun processPayment(payment: String, account: BankAccount): String {

    fun processIban(iban: BankAccount.Iban, paymentInfo: String): String {
        // Logic here
        return ""
    }

    fun processSwift(swift: BankAccount.Swift, paymentInfo: String): String {
        // Logic here
        return swift.bankName
    }

    return when (account) {
        is BankAccount.Iban -> processIban(account, payment)
        is BankAccount.Swift -> processSwift(account, payment)
    }
}

Is it an Exception replacement?

Yes and no.
I consider this way to be a much better fit to describe business logic rather than Exception flow because it is explicit and does not depend on a try-catch block, but for libraries or infrastructure-related code, Exceptions might be a better choice.
Just remember, Exception and DU are the only tools, and each tool has its own application area.

Performance optimization of negligently written code.

Ivan Pavlov — Sat, 14 Sep 2024 07:42:21 +0000

About

This project is a real case from my work about the consequences of negligent writing a simple mapper. Because the code from the project cannot be shared, I created a very similar mapper for weather observations.

How it begun

In one of my projects about refactoring, several endpoints run for more than a few seconds. We investigated the root cases for all slow endpoints and this story is about one of these investigations and fixes.
The endpoint runs about 30 seconds in a development environment (~16 seconds on my PC). After reading the call chain and short debugging, I quickly found out that the mapper took all the time except for ~100 ms.
The full code is available on GitHub

Rules

The purpose of the mapper is to merge data from two arrays of the Input record: Temperature[] Temperatures and string[] Places into a third array of the Output record.
The resulting array should be the same size as the Temperatures array and should contain values and dates from the Temperatures array. Data for states and seasons fields should be received from the Places array. Each date in the Temperatures array is unique.
The Places array can be less than, equal to, or greater than the Temperatures array.
The Places array contains strings that can have one, two, or three segments, with the ‘;’ delimiter. The first segment is a date in the format: month/day/year and the constant time stamp 00:00:00, the date is unique per array; this segment is always present. The second segment is two letters of a state and optional. The third segment is an abbreviation of a state and it and the delimiter are also optional. State and season abbreviations should be transformed into the full names of states and seasons, mappers should be case-insensitive.
Arrays should be matched by the date. If the Places array does not have a record with the corresponding date, or a record does not have the second and/or the third segment the states and/or seasons fields should be null.

Results

The benchmark results are placed in the result folder.
This is a table from the basic benchmark.

BenchmarkDotNet v0.13.11, Windows 11, AMD Ryzen 7 6800H.
.NET SDK 8.0.204
[Host] : .NET 8.0.8 (8.0.824.36612), X64 RyuJIT AVX2
DefaultJob : .NET 8.0.8 (8.0.824.36612), X64 RyuJIT AVX2

Method	N	Mean	Error	StdDev	Median	Ratio	RatioSD	Gen0	Gen1	Gen2	Allocated	Alloc Ratio
MapOriginal	10000	13,117.831 ms	120.0636 ms	112.3075 ms	13,117.128 ms	1,241.72	58.01	1568000.0000	25000.0000	-	12511.64 MB	2,437.84
MapOptimized	10000	12.582 ms	0.5073 ms	1.4957 ms	13.328 ms	1.00	0.00	875.0000	796.8750	484.3750	5.13 MB	1.00
MapOptimizedStruct	10000	5.494 ms	0.1072 ms	0.1002 ms	5.515 ms	0.52	0.02	570.3125	515.6250	390.6250	4.16 MB	0.81
MapOptimizedStructMarshal	10000	5.175 ms	0.0451 ms	0.0400 ms	5.183 ms	0.49	0.02	632.8125	585.9375	468.7500	3.39 MB	0.66

Why is it so slow?

The entry point is a small method called Map.
The main logic is placed in the MapSingle method where we can find the general computation recourse waster.

public static class Original
{
    private static readonly DateTimeFormatInfo DateTimeFormatInfo = new()
    {
        ShortDatePattern = "MM/dd/yyyy HH:mm:ss",
        LongDatePattern = "MM/dd/yyyy HH:mm:ss",
    };

    // The "entry point"
    public static Output[] Map(string json)
    {
        var data = JsonSerializer.Deserialize<Input>(json)!;
        return data.Temperatures.Select(t => t.MapSingle(data.Places)).ToArray();
    }

    // The main mapper
    private static Output MapSingle(this Temperature src, string[] places)
    {
        var data = GetData(src, places);
        var state = data?.Length > 1 ? data[1] : null;
        var season = data?.Length > 2 ? data[2].ToLower() : null;

        var mapSingle = new Output
        {
            Date = src.Date,
            Value = double.Parse(src.Value.ToString("0.##0")),
            State = GetState(state),
            Season = GetSeason(season)
        };
        return mapSingle;

        string[]? GetData(Temperature temperature, string[] strings)
        {
            // After some time reading the code, you can notice that this is a foreach cycle inside .Select cycle
            // for searching an element and this is the general computation recourse waster.
            foreach (var str in strings)
            {
                // The method creates a lot of allocations with new strings, but only the fist one is in use.
                var segments = str.Split(';');

                // To pass tests, paste the DateTimeFormatInfo as second argument here in DateTime.TryParse().  
                if (DateTime.TryParse(segments[0], out var result))
                {
                    if (DateTime.Equals(temperature.Date, result))
                    {
                        return segments;
                    }
                }
            }

            return null;
        }

        string? GetState(string? s1)
        {
            return s1 switch
            {
                "WA" => "Washington",
                "OR" => "Oregon",
                "NE" => "New York",
                "AL" => "Alaska",
                "CO" => "Colorado",
                _ => null
            };
        }

        string? GetSeason(string? s2)
        {
            return s2 switch
            {
                "wi" => "Winter",
                "sp" => "Spring",
                "su" => "Summer",
                "fall" => "Autumn",
                _ => null
            };
        }
    }
}

How to improve

We can significantly improve performance just by replacing the liner search in array/list with a dictionary, and more specifically, FrozenDictionary. This is an immutable, search-optimized dictionary that was introduced in .NET 8.
But should we limit ourselves to these changes because more places are far from good code?
For example, using the .Split() method creates new strings that should be analyzed and consumed by GC. It can be replaced by .AsSpan() with zero allocation on the heap.
These changes will not dramatically improve the performance of the specific method by improving the overall performance of the service by reducing pressure on GC.
After these improvements, the method execution time will be drastically decreased.

public static class Optimized
{
    private static readonly DateTimeFormatInfo DateTimeFormatInfo = new()
    {
        ShortDatePattern = "MM/dd/yyyy",
        LongDatePattern = "MM/dd/yyyy"
    };

    public static Output[] Map(string json)
    {
        var data = JsonSerializer.Deserialize<Input>(json)!;

        // The biggest performance changes are here - List has been replaced with FrozenDictionary. 
        var places = data.Places.ToFrozenDictionary(GetDate, GetSeasonState);

        return data.Temperatures.Select(t =>
        {
            places.TryGetValue(DateOnly.FromDateTime(t.Date), out var result);
            return new Output
            {
                Date = t.Date,
                Value = double.Round(t.Value, 3),
                Season = result.Season,
                State = result.State
            };
        }).ToArray();
    }

    private static DateOnly GetDate(string s)
    {
        return DateOnly.Parse(s.AsSpan(0, 10), DateTimeFormatInfo);
    }

    private static (string? Season, string? State) GetSeasonState(string s)
    {
        return (GetSeason(s), GetState(s));

        string? GetState(string str)
        {
            if (str.Length < 21)
                return null;

            // The contract is solid - we can use span with hardcoded values to use a part of the string.
            // It eliminates all heap allocations because Span is a ref struct.
            // It will not dramatically improve the performance of the specific method by improving the overall performance of the service.
            var state = str.AsSpan(20, 2);
            return state switch
            {
                { } when state.Equals("WA", StringComparison.OrdinalIgnoreCase) => "Washington",
                { } when state.Equals("OR", StringComparison.OrdinalIgnoreCase) => "Oregon",
                { } when state.Equals("CO", StringComparison.OrdinalIgnoreCase) => "Colorado",
                { } when state.Equals("AL", StringComparison.OrdinalIgnoreCase) => "Alaska",
                { } when state.Equals("NE", StringComparison.OrdinalIgnoreCase) => "New York",
                _ => null
            };
        }

        string? GetSeason(string str)
        {
            if (str.Length < 24)
                return null;

            var season = str.AsSpan()[23..];
            return season switch
            {
                { } when season.Equals("wi", StringComparison.OrdinalIgnoreCase) => "Winter",
                { } when season.Equals("sp", StringComparison.OrdinalIgnoreCase) => "Spring",
                { } when season.Equals("su", StringComparison.OrdinalIgnoreCase) => "Summer",
                { } when season.Equals("fall", StringComparison.OrdinalIgnoreCase) => "Autumn",
                _ => null
            };
        }
    }
}

Better results but higher complexity.

We can make the mapper even faster without diving into unsafe code and making the mapper readonly.
We can replace classes with structs for data-storage entities and if be precise we will use readonly record struct instead of records.

// Before
public record Output
{
    public DateTime Date { get; init; }
    public double Value { get; init; }
    public string? State { get; init; }
    public string? Season { get; init; }
}

public record Input(Temperature[] Temperatures, string[] Places);

public record Temperature(DateTime Date, double Value);

// After
public readonly record struct OutputSt
{
    public DateTime Date { get; init; }
    public double Value { get; init; }
    public string? State { get; init; }
    public string? Season { get; init; }
}

public readonly record struct InputSt(TemperatureSt[] Temperatures, string[] Places);

public readonly record struct TemperatureSt(DateTime Date, double Value);

Using struct is not as easy as using classes because of its nature. We must remember that when we pass a struct as an argument or return it from a method, all the data is copied.
For small structs like primitives, this is more than normal, but for large entities, it will lead to performance degradation.
But we can eliminate this problem simply by using ref / it / out to avoid data copying.
Another feature of structs is the structure of array and array-based collections.
An array of classes stores only links to an instance of that class in a heap, but an array of structs stores the whole struct itself.
I think an array of structs gives less memory fragmentation (but has better chances of being allocated in LOH), which will decrease the time spent getting an array element.
These small changes improve the method execution time twice.

public static class OptimizedStruct
{
    private static readonly DateTimeFormatInfo DateTimeFormatInfo = new()
    {
        ShortDatePattern = "MM/dd/yyyy",
        LongDatePattern = "MM/dd/yyyy"
    };

    public static OutputSt[] Map(string json)
    {
        var data = JsonSerializer.Deserialize<InputSt>(json);
        var places = data.Places.ToFrozenDictionary(GetDate, GetSeasonState);

        return data.Temperatures.Select(t =>
        {
            places.TryGetValue(DateOnly.FromDateTime(t.Date), out var result);
            return new OutputSt
            {
                Date = t.Date,
                Value = double.Round(t.Value, 3),
                Season = result.Season,
                State = result.State
            };
        }).ToArray();
    }

    private static DateOnly GetDate(string s)
    {
        return DateOnly.Parse(s.AsSpan(0, 10), DateTimeFormatInfo);
    }

    private static (string? Season, string? State) GetSeasonState(string s)
    {
        return (GetSeason(s), GetState(s));

        string? GetState(string str)
        {
            if (str.Length < 21)
                return null;

            var state = str.AsSpan(20, 2);
            return state switch
            {
                { } when state.Equals("WA", StringComparison.OrdinalIgnoreCase) => "Washington",
                { } when state.Equals("OR", StringComparison.OrdinalIgnoreCase) => "Oregon",
                { } when state.Equals("CO", StringComparison.OrdinalIgnoreCase) => "Colorado",
                { } when state.Equals("AL", StringComparison.OrdinalIgnoreCase) => "Alaska",
                { } when state.Equals("NE", StringComparison.OrdinalIgnoreCase) => "New York",
                _ => null
            };
        }

        string? GetSeason(string str)
        {
            if (str.Length < 24)
                return null;

            var season = str.AsSpan(23, str.Length - 23);
            return season switch
            {
                { } when season.Equals("wi", StringComparison.OrdinalIgnoreCase) => "Winter",
                { } when season.Equals("sp", StringComparison.OrdinalIgnoreCase) => "Spring",
                { } when season.Equals("su", StringComparison.OrdinalIgnoreCase) => "Summer",
                { } when season.Equals("fall", StringComparison.OrdinalIgnoreCase) => "Autumn",
                _ => null
            };
        }
    }
}

Another small boost.

We can slightly improve the performance by using a special method GetValueRefOrNullRef from the static class CollectionsMarshal to find an element and get a reference to it.
But FrozenDictionary has to be replaced with a usual Dictionary.
This manipulation gives us around a 6% boost over to the previous method.

public static class OptimizedStructMarshal
{
    private static readonly DateTimeFormatInfo DateTimeFormatInfo = new()
    {
        ShortDatePattern = "MM/dd/yyyy",
        LongDatePattern = "MM/dd/yyyy"
    };

    public static OutputSt[] Map(string json)
    {
        var data = JsonSerializer.Deserialize<InputSt>(json);
        var places = data.Places.ToDictionary(GetDate, GetSeasonState);

        return data.Temperatures.Select(t =>
        {
            // New way to find the element.
            ref var result = ref CollectionsMarshal.GetValueRefOrNullRef(places, DateOnly.FromDateTime(t.Date));
            return new OutputSt
            {
                Date = t.Date,
                Value = double.Round(t.Value, 3),
                Season = result.Season,
                State = result.State
            };
        }).ToArray();
    }

    private static DateOnly GetDate(string s)
    {
        return DateOnly.Parse(s.AsSpan(0, 10), DateTimeFormatInfo);
    }

    private static (string? Season, string? State) GetSeasonState(string s)
    {
        return (GetSeason(s), GetState(s));

        string? GetState(string str)
        {
            if (str.Length < 21)
                return null;

            var state = str.AsSpan(20, 2);
            return state switch
            {
                { } when state.Equals("WA", StringComparison.OrdinalIgnoreCase) => "Washington",
                { } when state.Equals("OR", StringComparison.OrdinalIgnoreCase) => "Oregon",
                { } when state.Equals("CO", StringComparison.OrdinalIgnoreCase) => "Colorado",
                { } when state.Equals("AL", StringComparison.OrdinalIgnoreCase) => "Alaska",
                { } when state.Equals("NE", StringComparison.OrdinalIgnoreCase) => "New York",
                _ => null
            };
        }

        string? GetSeason(string str)
        {
            if (str.Length < 24)
                return null;

            var season = str.AsSpan(23, str.Length - 23);
            return season switch
            {
                { } when season.Equals("wi", StringComparison.OrdinalIgnoreCase) => "Winter",
                { } when season.Equals("sp", StringComparison.OrdinalIgnoreCase) => "Spring",
                { } when season.Equals("su", StringComparison.OrdinalIgnoreCase) => "Summer",
                { } when season.Equals("fall", StringComparison.OrdinalIgnoreCase) => "Autumn",
                _ => null
            };
        }
    }
}

How to bypass the 30-second limit in AWS API Gateway.

Ivan Pavlov — Thu, 30 Nov 2023 17:08:33 +0000

Disclaimer

In this article, I will explain a solution to a problem I encountered while migrating web services from on-premises to AWS infrastructure and how I solved it.

I can't describe every detail of our project because it's under NDA, but I can paraphrase and create a similar solution on a demo project.

For simplicity and fast development, I used the standard weather forecast templates on .NET 7 for the Web.API and the Blazor WASM.
IMemoryCache is used to simplify the solution and code brevity. A solution using IDistributedCache will be similar in terms of business logic, but different in terms of a cache API, infrastructure code and amount of the code.

Problem

The goal of the project was to move a set of web services from on-premises to AWS and use cloud-native solutions where possible. For this reason, the AWS API Gateway was chosen to protect REST endpoints from the outside world.
During the development phase, we discovered that some REST endpoints require more than 30 seconds to execute, which exceeds the hardcode limit for both AWS API Gateway versions and cannot be changed in the near future. Probably the best solution, in this case, is a refactoring to increase performance. Still, the project tried to stick to the lift and shift approach and avoid modifying business logic. So, we needed a solution that could work for a while until the project finished migration to a new environment and new owner.

Solution

I made a demo project to demonstrate the code’s initial state and development process for solving the problem.
The endpoint may look like this:

[HttpGet("long-running/{id}")]
public async Task<ActionResult<WeatherForecast[]>> Get(string id)
{
    var result = await _dataService.LongRunningTask(id);
    return Ok(result);
}

And a method emulating long-running operations:

public async Task<WeatherForecast[]> LongRunningTask(string id)
{
    await Task.Delay(TimeSpan.FromSeconds(50));
    return new WeatherForecast[]
    {
        new()
        {
            Date = DateOnly.FromDateTime(DateTime.Now.AddDays(Random.Shared.Next(0, 6))),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = Summaries[Random.Shared.Next(Summaries.Length)]
        }
    };
}

The first idea

The first idea that comes to mind is to send back a response without waiting for the main code to execute. This approach is commonly used for a case with a message broker and a write operation, but in our case, the operation is reading data and we need to wait for it.

The most valuable idea that could solve this problem is to perform the calculation in the background and get a result when we need it. To implement this logic, we can use Task.Run() to send execution in the background and a cache to store data.

public WeatherForecast[]? GetOrCreateDataFirstIdea(string id)
{
    //Check if there is the entity in the cache
    if (_memoryCache.TryGetValue(id, out WeatherForecast[]? data))
        return data;

    Task.Run(async () =>
    {
        try
        {
            // Run the long running computation on backgroung
            var result = await _dataService.LongRunningTask(id);

            // Store the result in the cache
            _memoryCache.Set(id, result, absoluteExpirationRelativeToNow: TimeSpan.FromMinutes(15));
        }
        catch
        {
            // Log error
            _logger.LogError("_");
        }
    });

    return null;
}

The endpoint also needs to be changed in this way:

[HttpGet("in-memory-first-idea/{id}")]
public ActionResult<WeatherForecast[]> GetPullingInMemoryFirstIdea(string id)
{
    var result = _inMemoryCacheService.GetOrCreateDataFirstIdea(id);
    return result is null 
        ? NoContent()
        : Ok(result);
}

A front-end application must be refactored to use interval pooling to get the result. A Blazor UI variant can be seen at the end of this article.
An important part is a contact based on response codes. In our case, the server returns 204 if the requested entity is not in the cache and 200 if the entity is already computed.

This refactoring can solve the initial problem, but it is not ideal from a performance perspective because each new request creates a new long-running calculation on the same entity until one of them is finished and written to the cache.

Big improvement

We can improve the solution using the same cache – just store an additional value in the cache with a different key (determines that the entity is in the process of the calculation) and check the value in the cache at the beginning of the method.

public CacheServiceResult<WeatherForecast[]> GetOrCreateDataSecondIdea(string id)
{
    if (_memoryCache.TryGetValue(id + InCache, out WeatherForecast[]? data))
        return CacheServiceResult<WeatherForecast[]>.InCache(data!);

    // Store a "InProgress" value to mark the entity in the computation progress.
    if (_memoryCache.TryGetValue(id + InProgress, out _))
        return CacheServiceResult<WeatherForecast[]>.InProgress();

    Task.Run(async () =>
    {
        try
        {
            _memoryCache.Set(id + InProgress, id);
            var result = await _dataService.LongRunningTask(id);
            _memoryCache.Set(id + InCache, result, absoluteExpirationRelativeToNow: TimeSpan.FromMinutes(15));
        }
        catch
        {
            _logger.LogError("_");
        }
        finally
        {
            // Remove the "InProgress" value from the cahce
            _memoryCache.Remove(id + InProgress);
        }
    });

    // Returns the InProgress state, which indicates that the entity is in the process of being calculated.
    return CacheServiceResult<WeatherForecast[]>.InProgress();
}

The final solution

This code still has a place for improvement due to the error handling because each failed request will start a new calculation on the next request from the front-end application. If the delay between requests is short and the error is not transient, the server's resources will be wasted on unproductive computations.
To avoid this potential waste of resources, we can cache another value with a short lifetime and check for its presence at the beginning of the method.

public CacheServiceResult<WeatherForecast[]> GetOrCreateDataFinal(string id)
{
    if (_memoryCache.TryGetValue(id + InCache, out WeatherForecast[]? data))
        return CacheServiceResult<WeatherForecast[]>.InCache(data!);

    if (_memoryCache.TryGetValue(id + InProgress, out _))
        return CacheServiceResult<WeatherForecast[]>.InProgress();

    // Check the value that indicates that the computation of the requested entity terminated with an error. 
    if (_memoryCache.TryGetValue(id + Error, out _))
        return CacheServiceResult<WeatherForecast[]>.WithError();

    Task.Run(async () =>
    {
        try
        {
            _memoryCache.Set(id + InProgress, id);

            var result = await _dataService.LongRunningTask(id);

            _memoryCache.Set(id + InCache, result, absoluteExpirationRelativeToNow: TimeSpan.FromMinutes(15));
        }
        catch
        {
            _logger.LogError("_");
            // Store a value that that indicates that the computation of the requested entity terminated with an error.
            _memoryCache.Set(id + Error, id, absoluteExpirationRelativeToNow: TimeSpan.FromSeconds(5));
        }
        finally
        {
            _memoryCache.Remove(id + InProgress);
        }
    });

    return CacheServiceResult<WeatherForecast[]>.InProgress();
}

CacheServiceResult is a new entity containing an execution result and indicates the execution state.

public record CacheServiceResult<T>
{
    private CacheServiceResult(States state, T? entity)
    {
        State = state;
        Entity = entity;
    }

    public static CacheServiceResult<T> InProgress() => new(States.InProgress, default);
    public static CacheServiceResult<T> WithError() => new(States.Error, default);
    public static CacheServiceResult<T> InCache(T entity) => new(States.InCache, entity);

    public enum States
    {
        InProgress,
        InCache,
        Error
    }

    public States State { get; init; }
    public T? Entity { get; init; }
}

The front-end application on Blazor WASM

This is my implementation of a service in Blazor front-end application to request data with interval pooling.

public async IAsyncEnumerable<Result<WeatherForecast[]>> PullingWeatherForecasts(string id, [EnumeratorCancellation] CancellationToken cancellationToken)
{
    while (!cancellationToken.IsCancellationRequested)
    {
        var response = await _httpClient.GetAsync($"WeatherForecast/pulling-in-memory-cache/{id}", cancellationToken);
        switch (response.StatusCode)
        {
            case HttpStatusCode.OK:
                var stream = await response.Content.ReadAsStreamAsync(cancellationToken);
                var result = await JsonSerializer.DeserializeAsync<WeatherForecast[]>(stream, cancellationToken: cancellationToken);
                yield return new Result<WeatherForecast[]>(Result<WeatherForecast[]>.States.Finished, result!);
                yield break;
            case HttpStatusCode.NoContent:
                yield return new Result<WeatherForecast[]>(Result<WeatherForecast[]>.States.InProgress, Array.Empty<WeatherForecast>());
                break;
            case HttpStatusCode.InternalServerError:
                yield return new Result<WeatherForecast[]>(Result<WeatherForecast[]>.States.Error, Array.Empty<WeatherForecast>());
                break;
           default:
                throw new ArgumentOutOfRangeException();
        }

        await Task.Delay(TimeSpan.FromSeconds(3), cancellationToken);
    }
}

This is a part of the Weather forecast page from the standard Blazor WASM template

@page "/fetchdata"
***
@switch (_result.State)
{
    case Services.DataService.Result<WeatherForecast[]>.States.None:
        <p><em>Ready to load data.</em></p>
        break;
    case Services.DataService.Result<WeatherForecast[]>.States.InProgress:
        <p><em>Loading...</em></p>
        break;
    case Services.DataService.Result<WeatherForecast[]>.States.Finished:
        <p><em>Finished.</em></p>
        break;
    case Services.DataService.Result<WeatherForecast[]>.States.Error:
        <p><em>Error.</em>
        </p>break;
    default:
        throw new ArgumentOutOfRangeException();
}

@if (_result.State is Services.DataService.Result<WeatherForecast[]>.States.Finished)
{
    <table class="table">
        <thead><tr><th>Date</th><th>Temp. (C)</th><th>Temp. (F)</th><th>Summary</th></tr></thead><tbody>
        @foreach (var forecast in _result.Entity)
        {
            <tr><td>@forecast.Date.ToShortDateString()</td><td>@forecast.TemperatureC</td><td>@forecast.TemperatureF</td><td>@forecast.Summary</td></tr>
        }
        </tbody>
    </table>
}

@code {
    private readonly CancellationTokenSource _cancellationTokenSource = new();
    private DataService.Result<WeatherForecast[]> _result = new(Services.DataService.Result<WeatherForecast[]>.States.None, Array.Empty<WeatherForecast>());

    private async Task FetchWeatherForecasts()
    {
        var response = DataService.PullingWeatherForecasts("Type", _cancellationTokenSource.Token);
        await foreach (var result in response)
        {
            _result = result;
            StateHasChanged();
        }
    }

    public void Dispose()
    {
        _cancellationTokenSource.Cancel();
        _cancellationTokenSource.Dispose();
    }
}

Conclusion

This solution is well-fitted with the "lift and shift" approach, especially if the software is changing the legal owner. It took a couple of days for implementation and saved time for more important parts of our migration.