Nalar / independent articles for builders

Think clearly.
Build better.

A place to share practical knowledge and experience in programming and technology, with useful resources for software development, technology innovation, and real-world engineering problems.

Explore latest Browse tools

About this space 01

Practical writing about software, systems, and the small details that make products feel solid.

01 / Latest

Fresh from the notebook

Software Engineering 20 Sep 2026 6 min read

Visibility Timeouts Turn Message Delivery into a Renewable Lease

A queue consumer often needs time to perform work before it can safely acknowledge a message. Removing the message at receive time would make a consumer crash capable of losing work. Keeping it immediately available would let several consumers process the same item at once. A visibility timeout occupies the middle ground. Receiving a message makes it temporarily unavailable to competing consumers. The consumer gets a bounded interval to finish and acknowledge it. If that interval expires first, the queue can expose the message for another delivery.

Software Engineering Message Queues

Software Engineering 20 Sep 2026 6 min read

Transactional Outbox Keeps Database State and Events Aligned

A service often needs one operation to change database state and emit an event. An order may move to paid while OrderPaid must reach a message broker. Those two writes cross different systems, so a normal database transaction cannot make both commits atomic. Writing the database first leaves a gap: the process can stop after commit but before publishing. Publishing first creates the opposite gap: consumers can observe an event for a database change that later fails.

Software Engineering Transactional Outbox

Software Engineering 20 Sep 2026 6 min read

Token Buckets Separate Sustained Rate from Burst Capacity

A rate limit expressed only as “100 requests per second” leaves an important policy question open. Can a client send 100 requests at the first instant of each second, or must those requests be spread evenly? A token bucket makes that distinction explicit by separating sustained rate from burst capacity. The limiter maintains a balance of tokens up to a fixed capacity. Tokens arrive at a configured refill rate. An operation is admitted only when enough tokens are available, and admission deducts its cost from the balance. Idle time accumulates capacity for a later burst, but never beyond the bucket limit.

Software Engineering Rate Limiting

Cybersecurity 20 Sep 2026 6 min read

TLS SPKI Pinning Needs a Rotation Path

TLS SPKI Pinning Needs a Rotation Path Certificate pinning adds a local trust constraint to the certificate checks already performed by a TLS client. Instead of accepting any certificate that satisfies the configured PKI and service-identity rules, a pinned client also requires the connection to present cryptographic material that matches a value already embedded in, provisioned to, or otherwise trusted by the client. That narrower policy can reduce exposure to certificate issuance outside the intended key set. It also creates a new operational dependency: the client must carry a valid path from the key accepted today to a key that can be used after rotation.

Cybersecurity TLS

Cybersecurity 20 Sep 2026 6 min read

TLS Hostname Verification Binds a Valid Certificate to the Requested Name

TLS Hostname Verification Binds a Valid Certificate to the Requested Name A TLS certificate can be cryptographically valid and still be wrong for the server a client intended to reach. Chain validation answers whether the certificate can be linked to a configured trust anchor under the applicable PKI rules. Service identity verification answers a separate question: whether that certificate represents the hostname the client requested. Both checks are required for ordinary HTTPS authentication. Accepting a trusted certificate without checking the requested name turns a narrow credential into a credential for unrelated destinations.

Cybersecurity TLS

Cybersecurity 20 Sep 2026 7 min read

TLS Early Data Needs Replay-Safe Application Semantics

TLS Early Data Needs Replay-Safe Application Semantics TLS 1.3 can carry application data in the client’s first flight when the client and server share a suitable pre-shared key (PSK), commonly from an earlier connection. This mode is called early data or 0-RTT. It removes a handshake wait from the critical path for eligible application traffic, but the latency reduction comes with a narrower security contract. The central constraint is replay. TLS does not provide a non-replay guarantee for 0-RTT data across connections. A server can deploy anti-replay mechanisms, yet the application still has to treat early data as potentially replayed. That distinction matters whenever one accepted request can change durable state, consume a one-time capability, trigger an external action, or produce another effect that should occur only once.

Cybersecurity TLS 1.3

02 / Topics