Advanced topics (bonus)

#Event sourcing: events as the source of truthBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

When you need every meaningful transition and its reasons rather than only current state, event sourcing stores a sequence of events instead of replacing a state record. State is rebuilt by replay, while projections serve reads. This differs from adding an audit log beside an authoritative current-state table.

This C# sketch demonstrates replay only, not an event store; durable append needs an atomic expected-stream-version check.

public abstract record OrderEvent;
public sealed record OrderPlaced(decimal Total) : OrderEvent;
public sealed record OrderCancelled : OrderEvent;

public sealed class OrderState
{
    public decimal Total { get; private set; }
    public bool Cancelled { get; private set; }

    public void Apply(OrderEvent e) // (1)
    {
        switch (e)
        {
            case OrderPlaced placed: Total = placed.Total; break;
            case OrderCancelled: Cancelled = true; break;
        }
    }
}

var state = new OrderState();
foreach (var e in history) state.Apply(e); // (2): history is ordered OrderEvent data

Costs include schema evolution and upcasters, projection lag and rebuilds, and personal-data removal from long-lived history. Avoid it for ordinary CRUD without a real historical-state requirement. Event sourcing and CQRS do not require each other.

Event sourcing trade-offs

#GraphQL in .NET versus RESTBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

When mobile and web clients need different response shapes, GraphQL lets clients select fields from a typed schema. Hot Chocolate implements a GraphQL server in .NET. REST remains useful for straightforward contracts, HTTP caching and explicit business commands; neither approach is universally superior.

# GraphQL operation against an illustrative store schema
query {
  order(id: "123") {
    id
    lines { quantity product { name } }
  }
}

Resolvers can each issue a query, causing N+1. DataLoader batches key-based reads within a request, while projection limits columns. Require pagination and depth/cost limits, and authorize resources and fields. Fewer HTTP requests do not imply less database work. Never share a DataLoader cache across tenant boundaries. The operation is an illustrative contract, not a complete C# server.

Hot Chocolate batching

#Blazor render modes for backend developersBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

A Blazor Web App chooses where components execute interactively. This affects operations, security and latency, beyond page appearance.

Auto does not migrate a running component from server to browser mid-session. Interactive modes support prerendering by default; loading may occur in two phases, requiring state handling and prevention of duplicate side effects. Keep secrets and authorization on the server regardless of mode.

Render mode reference

@* In a .razor component after enabling the mode in the Blazor host. *@
@using static Microsoft.AspNetCore.Components.Web.RenderMode
@rendermode InteractiveServer
<button @onclick="Increment">Items: @count</button>
@code {
    private int count;
    private void Increment() => count++;
}

#The actor model and Microsoft OrleansBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

For per-entity state and behavior, such as bookings or carts, actors receive messages instead of exposing shared memory to arbitrary threads. Orleans provides virtual actors called grains, with stable identity, runtime-managed activation and distribution across silos.

Client -> Grain reference (BookingId) -> active grain on a silo
                                         |
                                  explicit persistent state
Silo failure -> later activation elsewhere -> reload persisted state

Default scheduling serializes requests for ordinary grains; reentrancy and interleaving settings change the reasoning. This is neither an automatic transaction across grains nor automatic persistence of every field. Design persistence, idempotency and timeouts explicitly. One heavily accessed entity can become a hot grain; more servers do not inherently split one key's workload. Simple CRUD may be easier without an additional cluster.

Orleans overview

#Dapr building blocksBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Dapr exposes common APIs for invocation, pub/sub and state across services and languages, backed by components for different providers. A common deployment uses an HTTP or gRPC sidecar. The broker and state store still exist and require configuration.

An abstraction does not guarantee identical transactions or consistency across stores. Test component metadata, retries, dead-letter behavior and permissions. Sidecar and operational costs may outweigh benefits for one simple API. Aspire handles local orchestration and service defaults; it does not automatically replace Dapr's runtime.

Dapr building blocks

#Feature flags: separating deployment from releaseBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Feature flags let you deploy code separately from enabling it, supporting gradual rollout. Microsoft.FeatureManagement provides evaluation, filters and variants. A flag is not authorization; permission checks remain necessary.

This service fragment assumes services.AddFeatureManagement(), an injected IVariantFeatureManager named features, and application-defined rendering methods.

using Microsoft.FeatureManagement;

bool useNewCheckout = await features.IsEnabledAsync("NewCheckout"); // (1)
return useNewCheckout
    ? RenderNewCheckout()
    : RenderCurrentCheckout();                                     // (2)

Give each flag an owner, purpose and removal date. Monitor cohort impact and define safe configuration-failure behavior. More flags create more combinations to test.

Feature management reference

#WebAssembly and WASI brieflyBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

WebAssembly is a portable execution format hosted by a runtime, inside or outside a browser. It can suit plugins, shared code or sandboxed workloads. WASI defines system interfaces available to WebAssembly according to the host and interface version; it is not a complete operating system.

Compiled module -> Wasm runtime -> explicitly granted host capabilities
Browser host: browser APIs and interop rules
WASI host: supported WASI interfaces and configured capabilities
Check .NET toolchain, runtime, interface version and package compatibility.

A sandbox still needs runtime updates and CPU/memory limits. Never put secrets in a client bundle, and do not assume arbitrary NuGet packages or ASP.NET Core apps run under WASI unchanged. .NET and WASI support evolves; verify the exact toolchain rather than promising universal compatibility.

WASI introduction

#gRPC streaming and connection lifetimeBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

For progress updates or event streams, gRPC supports unary, server-streaming, client-streaming and bidirectional calls. Proto contracts generate C# types. This finite server-streaming example is not a durable event subscription.

syntax = "proto3";
option csharp_namespace = "Store.Contracts";
service Progress { rpc Watch (WatchRequest) returns (stream ProgressReply); }
message WatchRequest { string order_id = 1; }
message ProgressReply { int32 percent = 1; }

// In a Grpc.AspNetCore project with C# generated from the proto above.
using Grpc.Core;
using Store.Contracts;

public sealed class ProgressService : Progress.ProgressBase
{
    public override async Task Watch(WatchRequest request,
        IServerStreamWriter<ProgressReply> stream, ServerCallContext context)
    {
        for (int n = 0; n <= 100; n += 25)
        {
            context.CancellationToken.ThrowIfCancellationRequested(); // (1)
            await stream.WriteAsync(new ProgressReply { Percent = n }); // (2)
            await Task.Delay(100, context.CancellationToken);
        }
    }
}

Check proxy timeouts and HTTP/2 support. Browsers need gRPC-Web or another approach; gRPC-Web does not provide native client or bidirectional streaming. If event loss is unacceptable, reconnect requires a resume cursor and deduplication; opening a new connection alone does not replay data.

gRPC service contracts

#YARP as a reverse proxyBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

To route some requests to a new service and keep others on a legacy system, YARP provides a reverse-proxy library hosted in ASP.NET Core. Routes match requests; clusters define destinations and load-balancing behavior. It suits incremental migration or a customized gateway, with operations remaining your responsibility.

This uses Yarp.ReverseProxy and a validated ReverseProxy configuration section containing routes and clusters; the fragment does not define destinations by itself.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy")); // (1)
var app = builder.Build();
app.MapReverseProxy();                                               // (2)
app.Run();

Review trusted forwarded headers, TLS, health checks, timeouts, request sizes and trace propagation. A reverse proxy is not automatically a full service mesh or WAF. A managed gateway may meet the need with less operational work.

YARP setup

#Hangfire, Quartz and TemporalBonus

Optional but valuable: not asked in every interview, but knowing it deepens your understanding and sets you apart.

Task.Run inside a request is not a job system: the process may stop and the request scope may disappear. Choose based on whether you need persisted jobs, rich scheduling or long-running workflows that recover progress.

Temporal activities contain I/O and side effects. Workflows replay from history, so use SDK primitives instead of ordinary clocks, randomness or HTTP calls. Activities can repeat and need idempotency. For every tool, monitor oldest-job age, failures and retries; use an outbox when enqueue intent must be atomic with business writes.

Hangfire · Quartz.NET · Temporal .NET