DEV Community: GigAHerZ

Why I Over-Engineered a ULID Library for .NET

GigAHerZ — Tue, 07 Apr 2026 13:30:00 +0000

Unique identifiers are often treated as an afterthought, but for senior engineers and architects, they represent a critical choice in system design. "Good enough" identifiers are a ticking time bomb of index fragmentation and degraded performance.

Why ULID over UUIDv7?

While UUIDv7 is a step forward, its specification makes monotonicity optional. During high-concurrency bursts, many generators sacrifice order to stay fast. ByteAether.Ulid refuses this compromise. By mandating strict lexicographical sortability, it ensures your database indexes remain optimized and sequential.

Solving the Overflow Problem

A common failure point in ULID implementations is the 80-bit random component overflow. High-volume systems can easily exhaust the random space within a single millisecond, causing standard libraries to throw an OverflowException.

ByteAether.Ulid handles this by automatically incrementing the timestamp component. This ensures unique, sorted IDs continue to generate even under extreme load, providing a level of resilience that standard implementations lack.

Performance via CAS Strategy

In high-throughput environments, traditional locking mechanisms introduce significant overhead and latency. ByteAether.Ulid utilizes a lock-free compare-and-exchange (CAS) strategy to manage state.

By avoiding heavy OS-level locks and using hardware-level atomics to achieve the same synchronization, we eliminate the latency typical of normal locking mechanisms. This allows threads to resolve state changes with minimal friction, maximizing CPU efficiency while maintaining strict thread safety.

Strategic Features

Anti-Enumeration: Configurable random increments prevent attackers from guessing sequential IDs.
Temporal Queries: Use Ulid.MinAt() and Ulid.MaxAt() to perform range queries on your primary key without needing a CreatedAt column.
Zero Allocations: Optimized for standard generation paths to reduce GC pressure.

I have documented the full engineering rationale and performance benchmarks in a detailed post on my blog. If you are interested in the nuances of distributed system design, I invite you to read the full version.

Moving Beyond O(N^2 log N) for Weighted Random Sorting

GigAHerZ — Wed, 07 Jan 2026 14:30:00 +0000

In high-volume traffic routing, we often need a "fail-over" list: a fully sorted list of destinations where the first item is the most likely candidate, but subsequent items are available if the primary fails.

The Starvation Problem

Sorting purely by success rate is a mistake. It directs 100% of traffic to the top service, leaving others with no traffic to prove they have recovered from a previous failure. We need weighted randomization to ensure every service gets "exploration" traffic.

The Better Way: Efraimidis-Spirakis

Instead of an iterative loop that picks and removes items, we can use a specialized form of Reservoir Sampling. The Efraimidis-Spirakis paper demonstrates that we can generate a weighted permutation in a single pass.

The logic is simple:

Generate a random double u between 0 and 1.
Calculate a sort key: u^(1/weight).
Sort the list by this key in descending order.

Scalability and Streams

This approach reduces complexity to O(N log N) and works perfectly for data streams. You can assign a sort key to an item the moment it arrives, making it ideal for high-throughput systems where performance is critical.

I've written a more detailed post on my personal blog that compares C# implementations and dives deeper into the math.

Check out the full post on my blog: https://byteaether.github.io/2026/the-weight-of-decisions-solving-weighted-random-sorting-at-scale/

ULID 1.3.2 is here: .NET 10 support, C# 14 field keyword for zero-overhead validation, and intelligent overflow prevention. Essential reading for .NET architects & senior engineers. #dotnet #csharp #ulid #performance

GigAHerZ — Thu, 18 Dec 2025 15:14:45 +0000

ByteAether.Ulid 1.3.2: .NET 10 Support, C# 14's Field, and Engineering Zero-Overhead IDs

GigAHerZ ・ Nov 14

#csharp #dotnet #webdev #news

Finalizing the Enterprise DAL series! We implement Automated User Auditing (`CreatedByUserId`/`ModifiedByUserId`) and review the full architecture that automated Soft-Delete, Multi-Tenancy, and RLS. C# & Linq2Db. #dotnet #csharp #architecture #sql

GigAHerZ — Thu, 04 Dec 2025 22:05:25 +0000

GigAHerZ

Dec 2 '25

Enterprise DAL Final: Automated User Auditing and Architectural Retrospective

#database #architecture #automation #csharp

Comments

2 min read

Enterprise DAL Final: Automated User Auditing and Architectural Retrospective

GigAHerZ — Tue, 02 Dec 2025 13:00:00 +0000

This post marks the end of our series on constructing an enterprise-grade Data Access Layer (DAL) in C# with Linq2Db. Our goal was to create a DAL that is secure and resilient by automatically handling crucial cross-cutting concerns.

Implementing Automated User Auditing

To achieve compliance and enhance debugging, we implement Automated User Auditing. This feature automatically populates CreatedByUserId and ModifiedByUserId fields with the current user's unique identifier (Ulid).

The implementation is integrated into our existing interface-driven architecture:

Contracts: New interfaces (IUserCreatable, IUserModifiable) define the required properties.
Automation: Our custom scaffolding ensures that any entity table with created_by_user_id/modified_by_user_id columns automatically implements these interfaces.
Injection Logic: We update our CrudExtensions to inspect the entity on create/modify operations. If the entity implements the auditing interface, the current UserId from the request-scoped context is injected before the database operation executes.

Crucial detail for Architects: We detail a necessary, advanced technique using (LinqToDB.Internal.Linq).Internals.GetDataContext(source) to correctly inject the ModifiedByUserId user ID during fluent batch UPDATE operations (IUpdatable<T>). This ensures auditing integrity across all modification types.

Verdict: 100% Goal Achievement

The final architecture successfully automated every requirement initially set for a perfect enterprise DAL:

Ubiquitous Filtering: Soft-Delete, Multi-Tenancy, and Row-Level Security are enforced by a highly composable global query filter system, transparently generating the correct SQL joins and WHERE clauses for all read operations.
Projected Security: The use of Linq2Db’s projection capabilities allows for complex security and tenancy rules to be resolved contextually from related entities, a key differentiator.
Auditing: Timestamp and User auditing are handled automatically on creation and modification.

This robust DAL abstracts away security and compliance boilerplate, letting developers focus purely on business logic.

For the full implementation details, including source code and an in-depth explanation of the global query filter system, read the complete article on my blog.

Stop writing RLS filters. Build a composable DAL that enforces Row-Level Security automatically. Fail-closed, projected permissions that compose perfectly with Soft-Deletes & Multi-Tenancy. Essential reading for architects. See the generated SQL!

GigAHerZ — Mon, 01 Dec 2025 13:53:20 +0000

Building Composable RLS: Enterprise Data Security on Autopilot

GigAHerZ ・ Nov 25

#dotnet #architecture #csharp #security

Building Composable RLS: Enterprise Data Security on Autopilot

GigAHerZ — Tue, 25 Nov 2025 14:00:00 +0000

Enterprise applications require rigorous data integrity and security, but manually implementing these cross-cutting concerns is error-prone. This post, the (almost) final in our series on building an automated Data Access Layer (DAL), focuses on implementing the most challenging requirement: Row-Level Security (RLS).

We build upon our existing system of composable global query filters, extending it to enforce entity-based RLS automatically. This means a developer writes a simple query, and the DAL guarantees that only records accessible to the current user are returned, even for complex joins.

The RLS Contract: `IProtected`

To enable this, we update our IDbCtx to carry the authenticated user's Ulid? UserId. A key security choice is to adopt a "fail-closed" stance: if UserId is null, the query will be filtered to return no rows.

We define the security behavior with the IProtected interface.

[EntityFilter<IProtected>(nameof(Filter))]
public interface IProtected
{
    // The entity must expose the ID used for the permission check.
    Ulid GetPermissionObjectId();
    // Filter method dynamically applies an INNER JOIN to permissions table.
}

The filter method attached via [EntityFilter] performs two critical steps:

Unauthenticated Check: If no UserId is set in the context, it returns q.Where(_ => false). Access denied.
Permission Join: If a user is present, it executes an InnerJoin between the entity query and the IPermissionEntity table. This join is conditional on perm.ObjectId matching the entity's object ID, and perm.SubjectId matching the current user's ID.

Projected Permissions for Scalability

What if permissions are hierarchical? For instance, a user is granted access to a Post, but needs to query its child Comments. Our architecture handles this by allowing the Comment entity to "project" its security check to its parent's ID.

public partial class Comment : IProtected
{
    // Tells the RLS filter to use the Post ID for the security check.
    [ExpressionMethod(nameof(GetPermissionObjectIdExpression))]
    public Ulid GetPermissionObjectId() => Post.Id;

    private static Expression<Func<Comment, Ulid>> GetPermissionObjectIdExpression()
        => x => x.Post.Id;
}

The DAL automatically converts this method call into an expression tree that joins the Comment table to the Post table, then joins the Post to the Permission table. All the complexity of multi-table security is handled by the DAL framework, not the application code.

The Result: Guaranteed Compliance

When a developer executes a simple ModifyAsync() on a protected, tenanted, and soft-deletable Comment entity, the DAL composes all four concerns into a single, efficient, and guaranteed-correct SQL statement. This eliminates common security and data integrity vulnerabilities from the application layer.

For the full source code, the detailed filter logic, and the final generated SQL, check out the complete article on our blog.

Architects: Stop relying on business logic for multi-tenancy. We show how to enforce non-bypassable data isolation at the DAL using C#, Linq2Db, and expression trees. Essential security for enterprise apps! #multitenancy #csharp #linq2db

GigAHerZ — Mon, 24 Nov 2025 12:42:27 +0000

Building a Secure DAL: Composable Multi-Tenancy Filtering with C# and Linq2Db

GigAHerZ ・ Nov 13

#csharp #dotnet #security #architecture

ByteAether.Ulid 1.3.2: .NET 10 Support, C# 14's Field, and Engineering Zero-Overhead IDs

GigAHerZ — Fri, 14 Nov 2025 13:00:00 +0000

We are thrilled to announce the release of ByteAether.Ulid version 1.3.2, now available on NuGet. This new version introduces full support for .NET 10 and finalizes our aggressive adoption of modern C# features to deliver the fastest, most secure, and most spec-compliant ULID implementation in .NET.

Our library is engineered for senior developers and architects focused on high-throughput services. We tackle critical identifier generation problems, including robust overflow handling and secure monotonic increments.

Dedicated .NET 10 Binaries

The primary feature of 1.3.2 is the inclusion of build artifacts specifically compiled against the .NET 10 SDK.

Our multi-targeting strategy is fundamental to our performance guarantee. We don't ship a single .NET Standard 2.0 assembly; instead, we provide optimized binaries for .NET 10, 9, 8, 7, 6, 5, and .NET Standard 2.1 and 2.0.

When you install the package, NuGet selects the .NET 10 binary, which is compiled with the latest JIT intrinsics and BCL (Base Class Library) improvements. This allows our codebase, which is rich with conditional compilation, to leverage the most powerful APIs available on each platform, including optimized ReadOnlySpan<T>, MemoryMarshal, and SIMD instructions for Base32 operations. This is key to our benchmark-leading speed.

The C# 14 `field` Keyword: Eliminating Hot Path Overhead

To ensure our ID generation is as fast as possible, we must eliminate all unnecessary overhead from the Ulid.New() hot path.

We use the new C# 14 field keyword within our GenerationOptions record for "fail-fast" validation. This design choice ensures that configuration validation runs only once when the configuration object is constructed, not inside the generation loop.

For example, ensuring the Monotonicity property is valid occurs during init:

public MonotonicityOptions Monotonicity
{
    get;
    init => field = Enum.IsDefined(typeof(MonotonicityOptions), value)
        ? value
        : throw new ArgumentOutOfRangeException(/* ... */);
}

This single-time validation guarantees that any call to Ulid.New() operates with a pre-validated, zero-overhead configuration, a crucial optimization for high-volume systems.

Robustness: Programmatic Overflow Prevention

Reliability is as vital as performance. A common, though often unaddressed, problem is the OverflowException that can occur during rapid ULID generation within the same millisecond. This happens because the 80-bit random component can, by chance, start near its maximum value.

Our library solves this programmatically: when a random component overflow is imminent, we intelligently increment the 48-bit timestamp component by 1ms. This small, controlled time jump ensures continuous, error-free generation while maintaining the lexicographical sort order.

The GenerationOptions also supports advanced security, allowing control over the IRandomProvider and offering granular MonotonicityOptions (like MonotonicRandom1Byte) to defend against enumeration attacks.

Conclusion

The 1.3.2 release of ByteAether.Ulid provides .NET 10 support and leverages cutting-edge C# features to deliver a ULID implementation optimized for performance, security, and meticulous specification compliance.

We encourage you to adopt ByteAether.Ulid if your identifier generation strategy requires speed and robust design.

Read the full technical analysis and deep dive into the code on our blog. https://byteaether.github.io/2025/announcing-byteaetherulid-132-net-10-support-and-optimized-design/

Building a Secure DAL: Composable Multi-Tenancy Filtering with C# and Linq2Db

GigAHerZ — Thu, 13 Nov 2025 14:00:00 +0000

Securing a multi-tenant application means enforcing strict data isolation. This cannot be left to business logic, but it must be guaranteed at the Data Access Layer (DAL). We built upon our existing enterprise DAL foundation to implement automated, non-bypassable multi-tenancy filtering.

This article summarizes the key architectural steps for senior engineers and architects looking to solve this critical cross-cutting concern.

The Problem and Our Goal

The goal is to ensure that every query executed against a tenant-aware entity is automatically filtered by the current tenant's ID. We need this filter to compose seamlessly with other existing global filters, such as soft-delete.

1. Passing Tenant Context to the DAL

Our DAL must be tenant-aware. We update our base database context interface, IDbCtx, to hold request-scoped attributes, starting with the TenantId.

public interface IDbCtx : IDataContext
{
    DbCtxAttributes Attributes { get; set; }
    public record DbCtxAttributes(Ulid TenantId = default);
}

This attribute is initialized early in the request lifecycle, ensuring the current TenantId is available for the database context's lifetime.

2. Defining the Tenancy Contract

We use an ITenanted interface to define the behavior and attach the filtering logic. The [EntityFilter] attribute ties the interface to the static Filter method, which contains the LINQ Where clause.

[EntityFilter<ITenanted>(nameof(Filter))]
public interface ITenanted : IEntity
{
    Ulid TenantId { get; }
    private static IQueryable<T> Filter<T>(IQueryable<T> q, IDbCtx ctx)
        where T : ITenanted
        => q.Where(x => x.TenantId == ctx.Attributes.TenantId);
}

Our global filter system discovers this attribute and automatically applies this Where clause to every query against implementing entities.

3. Solving Projected Tenancy

Not all entities have a direct tenant_id column. A Post, for example, may inherit its tenancy from its parent User. This is "Projected Tenancy."

To handle this, we manually implement ITenanted for the Post entity and use the Linq2Db [ExpressionMethod] attribute. This instructs Linq2Db to translate the property access into a SQL expression involving a join.

public partial class Post : ITenanted
{
    [ExpressionMethod(nameof(GetTenantIdExpression))]
    public Ulid TenantId => GetTenantIdExpression().Compile()(this);

    private static Expression<Func<Post, Ulid>> GetTenantIdExpression()
        => x => x.User.TenantId;
}

Linq2Db parses the expression x => x.User.TenantId, generating an INNER JOIN to the user table and applying the tenant filter to the joined user's tenant_id column.

Conclusion: Composable Security

This architecture allows security rules to be defined once and enforced automatically. The generated SQL proves that soft-delete rules and multi-tenancy rules are correctly layered, guaranteeing both data integrity and isolation.

For the complete implementation, including scaffolding automation and the full generated SQL analysis, see the full article on my blog.

Stop manual soft-delete filtering. We built a composable architecture using Global Query Filters that automatically hides deleted records from all queries, even entity associations. Converts `DELETE` to auditable `UPDATE`. Read the full architecture.

GigAHerZ — Tue, 11 Nov 2025 14:24:29 +0000

Enterprise Data Access: Fully Automated Soft-Delete

GigAHerZ ・ Nov 6

#database #architecture #dotnet #csharp

Enterprise Data Access: Fully Automated Soft-Delete

GigAHerZ — Thu, 06 Nov 2025 14:00:00 +0000

In professional software development, permanent data deletion is often a non-starter. Auditing, compliance, and recovery mandates require that we soft-delete records, marking them as inactive rather than physically removing them.

The implementation, however, is a common source of bugs and security vulnerabilities. A manual approach requiring developers to remember a Where(x => x.RemovedAt == null) clause on every query is simply untenable.

Architectural Imperatives

A production-grade soft-delete system must satisfy two non-negotiable requirements automatically:

Read Consistency: Soft-deleted records must be filtered from every SELECT query in the application.
Association Filtering: The filter must propagate when querying entity associations. Loading a Post must automatically exclude any soft-deleted Comments from its collection.

We achieved this by centralizing the logic using Global Query Filters and engineering a composable filter architecture.

The Composable Filter Solution

A major limitation with many ORMs is the restriction to a single Global Query Filter per entity. Enterprise systems, however, require multiple cross-cutting concerns: soft-delete, multi-tenancy, and row-level security, each needing its own filter.

Our solution is a system that aggregates multiple filter expressions:

Behavior Definition: An interface like IRemovable defines the RemovedAt property and uses a custom attribute to point to its static filtering method.
Dynamic Composition: At runtime, a process scans the entity hierarchy for all filtering attributes. It collects all individual filter lambdas (e.g., x.RemovedAt == null, x.TenantId == @CurrentTenant) and combines them using the logical AND operator (Expression.AndAlso).
Application: The single, resulting aggregated expression is applied as the entity's Global Query Filter, ensuring all required conditions are met automatically on every query.

This system guarantees that any entity implementing IRemovable is always filtered correctly, regardless of how or where it is queried.

Transparent Delete Interception

To ensure data integrity and full auditability, we must intercept the DELETE command.

We implement new RemoveAsync extension methods that check for the IRemovable interface. When present, instead of executing a physical DELETE, the DAL executes a secure UPDATE statement that sets the RemovedAt timestamp.

This not only performs the soft-delete but, by chaining into our existing data modification logic, also automatically updates the ModifiedAt timestamp, giving us a complete audit trail for the "deletion."

The output SQL is a confirmation of success: the hard delete is converted into an auditable update, and the global filter is even applied to the update query itself to prevent re-deleting an already soft-deleted record.

Conclusion and Next Steps

By moving soft-delete from an application concern to a core DAL feature, we have eliminated a significant source of developer error and enhanced system security and consistency. The composable filter system is the key takeaway, providing a pattern for managing multiple cross-cutting data concerns simultaneously.

This foundational architecture is now being leveraged to implement our next critical feature: multi-tenancy.

For the full source code and complete architectural deep dive, visit the original article on my blog.

DEV Community: GigAHerZ

Why I Over-Engineered a ULID Library for .NET

Why ULID over UUIDv7?

Solving the Overflow Problem

Performance via CAS Strategy

Strategic Features

Moving Beyond O(N^2 log N) for Weighted Random Sorting

The Starvation Problem

The Better Way: Efraimidis-Spirakis

Scalability and Streams

ULID 1.3.2 is here: .NET 10 support, C# 14 field keyword for zero-overhead validation, and intelligent overflow prevention. Essential reading for .NET architects & senior engineers. #dotnet #csharp #ulid #performance

ByteAether.Ulid 1.3.2: .NET 10 Support, C# 14's Field, and Engineering Zero-Overhead IDs

GigAHerZ ・ Nov 14

Finalizing the Enterprise DAL series! We implement **Automated User Auditing** (`CreatedByUserId`/`ModifiedByUserId`) and review the full architecture that automated Soft-Delete, Multi-Tenancy, and RLS. C# & Linq2Db. #dotnet #csharp #architecture #sql

Enterprise DAL Final: Automated User Auditing and Architectural Retrospective

Enterprise DAL Final: Automated User Auditing and Architectural Retrospective

Implementing Automated User Auditing

Verdict: 100% Goal Achievement

Stop writing RLS filters. Build a composable DAL that enforces Row-Level Security automatically. Fail-closed, projected permissions that compose perfectly with Soft-Deletes & Multi-Tenancy. Essential reading for architects. See the generated SQL!

Building Composable RLS: Enterprise Data Security on Autopilot

GigAHerZ ・ Nov 25

Building Composable RLS: Enterprise Data Security on Autopilot

The RLS Contract: IProtected

Projected Permissions for Scalability

The Result: Guaranteed Compliance

Architects: Stop relying on business logic for multi-tenancy. We show how to enforce non-bypassable data isolation at the DAL using C#, Linq2Db, and expression trees. Essential security for enterprise apps! #multitenancy #csharp #linq2db

Building a Secure DAL: Composable Multi-Tenancy Filtering with C# and Linq2Db

GigAHerZ ・ Nov 13

ByteAether.Ulid 1.3.2: .NET 10 Support, C# 14's Field, and Engineering Zero-Overhead IDs

Dedicated .NET 10 Binaries

The C# 14 field Keyword: Eliminating Hot Path Overhead

Robustness: Programmatic Overflow Prevention

Conclusion

Building a Secure DAL: Composable Multi-Tenancy Filtering with C# and Linq2Db

The Problem and Our Goal

1. Passing Tenant Context to the DAL

2. Defining the Tenancy Contract

3. Solving Projected Tenancy

Conclusion: Composable Security

Stop manual soft-delete filtering. We built a composable architecture using Global Query Filters that automatically hides deleted records from all queries, even entity associations. Converts `DELETE` to auditable `UPDATE`. Read the full architecture.

Enterprise Data Access: Fully Automated Soft-Delete

GigAHerZ ・ Nov 6

Enterprise Data Access: Fully Automated Soft-Delete

Architectural Imperatives

The Composable Filter Solution

Transparent Delete Interception

Conclusion and Next Steps

Finalizing the Enterprise DAL series! We implement Automated User Auditing (`CreatedByUserId`/`ModifiedByUserId`) and review the full architecture that automated Soft-Delete, Multi-Tenancy, and RLS. C# & Linq2Db. #dotnet #csharp #architecture #sql

The RLS Contract: `IProtected`

The C# 14 `field` Keyword: Eliminating Hot Path Overhead