DEV Community: Shubham Anandani

Revocation Is the Hard Part

Shubham Anandani — Tue, 25 Aug 2026 19:00:00 +0000

Issuing verifiable credentials is straightforward: define a claim, sign it, return it to the holder. Revocation is harder: you need to detect when a credential should no longer be accepted, ideally without creating a surveillance channel that reveals who asked and when.

The failure mode

A verifier calls a central revocation endpoint for every check. The endpoint sees who asked (IP or key), when, for which credential ID, and what outcome occurred. Even if the credential is privacy-preserving, the revocation lookup becomes a “phone home” channel that leaks context. Users and regulators won’t love that.

What I learned

Understand the revocation design space

Status list (offline)

The issuer publishes a privacy-preserving list of credential status values (for example, a bitstring status list) that verifiers fetch periodically. Verification checks against the local list.

Online status check

The verifier queries a status endpoint per credential. Freshness improves; privacy worsens.

Holder stapling

The holder obtains a fresh status attestation and presents it along with the credential. The verifier checks the stapled proof without contacting the issuer per verification.

Short-lived credentials:

Expire credentials quickly so revocation windows are short. This reduces reliance on revocation checks.

Privacy-preserving lists: batch and compress

A status list can represent many credentials without revealing individual identities. Verifiers download the list on a schedule (e.g., every policy-defined freshness window), cache it locally, and check bits/entries offline. Lists can be partitioned or hashed to limit list size.

Stapling shifts “phone home” to holder flow

With stapling, the holder requests a status proof from the issuer (or a delegated service) at a cadence, then presents it to verifiers. This avoids per-verification lookups by verifiers but still requires the holder to contact the issuer on some schedule. The privacy difference is who calls whom and when.

Short-lived credentials reduce time at risk

If credentials expire quickly, revocation needs are less acute. This shifts load from revocation infrastructure to issuance (more frequent renewals). Combine with holder stapling to keep verification fast and private.

Model cache freshness and failure modes

Verifiers should track the freshness of status lists. If a list is too old (e.g., beyond your policy window), treat the result as “unverifiable” rather than “accepted,” and prompt re-fetch or stapling. Distinguish “cache stale” from “revoked.”

Avoid per-ID URLs in logs

If you must hit an online status endpoint, avoid logging per-ID lookups in a way that identifies a particular holder or verifier. Aggregate metrics instead. Keep any necessary identifiers hashed or pseudonymous.

Distinguish revocation from expiry and audience

Revocation says “this specific credential is no longer valid.” Expiry says “credentials of this type are only valid until T.” Audience says “this verifier is permitted to consume the claim.” Don’t overload revocation with other policy failures.

Illustrative status-list freshness check

from dataclasses import dataclass
from datetime import datetime, timezone

@dataclass(frozen=True)
class StatusSnapshot:
    fetched_at: datetime
    bits: bytes

def is_fresh(snapshot: StatusSnapshot, max_age_seconds: int) -> bool:
    age = datetime.now(timezone.utc) - snapshot.fetched_at
    return age.total_seconds() <= max_age_seconds

# Choose the freshness window from policy and operational requirements.
# Stale status should have an explicit outcome, such as "unverifiable".

Trade-offs and failure modes

Trade-offs

Offline lists vs freshness: Lists preserve privacy but can be stale. Address with frequent, batched updates.
Stapling vs issuer load: Stapling shifts calls to holders; the issuer still handles periodic status proofs. Load is manageable with caching and rate limits.
Short-lived credentials vs user friction: Frequent renewals add UX overhead. Balance with clear prompts and automated refresh flows.

Failure modes

“Phone home”: Per-verification lookups leak context. Solution: offline lists or stapling.
“Stale cache”: Verifiers use outdated lists. Solution: freshness checks and policy windows that treat stale as “unverifiable.”
“Revocation conflation”: Treating expiry or audience failure as revocation. Solution: separate policy checks.

Try it yourself

Implement an offline status list with a freshness window. Treat stale lists as “unverifiable.”
Add holder stapling to your demo: the holder fetches a status proof and presents it alongside the credential.
Track performance for offline list checks vs online status calls. Compare privacy and tail behavior.

Designing for Partial Data: Distinguishing “We Don’t Know” From “False”

Shubham Anandani — Sat, 22 Aug 2026 19:00:00 +0000

Partial data is normal. Missing signals and unverifiable sources happen. If you collapse “unknown” into “false” or “zero,” you erode trust. As an engineering manager, I’ve learned to design services that treat “we don’t know” as a first-class outcome. In Java, sealed types and exhaustive pattern matching make this straightforward and enforceable.

The failure mode

Your aggregator treats null as “0.0,” sums four dimensions, and displays a neat number. A caller misreads that as “complete and low.” In reality, two dimensions were missing, and one was unverifiable. The number masked uncertainty.

What I learned

Model the states as a sealed type

public sealed interface ScoreOrUnknown permits Score, Missing, Unverifiable {}

public record Score(double value) implements ScoreOrUnknown {}
public record Missing(String reason) implements ScoreOrUnknown {}
public record Unverifiable(String note) implements ScoreOrUnknown {}

Keep partial states in the domain layer, not just at the edges

Don’t convert unknowns to defaults at the boundary. Let domain logic operate on sealed types. If you must produce a single number, force policy conversion in a dedicated function so that the decision is auditable.

Policy example

public final class AggregationPolicy {

    public static double conservativeAverage(List<ScoreOrUnknown> dims) {
        int count = 0;
        double sum = 0.0;
        for (ScoreOrUnknown d : dims) {
            switch (d) {
                case Score sc -> { sum += sc.value(); count++; }
                case Missing miss -> { /* exclude; track missing elsewhere */ }
                case Unverifiable unv -> { /* exclude; track unverifiable */ }
            }
        }
        if (count == 0) return Double.NaN; // no numeric evidence
        return sum / count;
    }

    public static boolean okToDisplay(List<ScoreOrUnknown> dims) {
        long unknowns = dims.stream().filter(x -> !(x instanceof Score)).count();
        return unknowns == 0; // or choose a threshold
    }
}

Propagate uncertainty deliberately

Unknowns should travel with the data: into logs, decisions, and UI. For example, if two dimensions are unknown, surface that count alongside any numeric aggregation. The goal is to prevent silent conversions that distort confidence.

Make unknown-handling policies explicit and testable

Write tests that assert what happens when all dimensions are unknown, when some are missing, and when a single unverifiable dimension appears. Pattern matching keeps these tests aligned with the domain states. Don’t assume a “best effort” numeric default; decide and encode.

Resist “default values” in DTOs

If you serialize to JSON, include a type field in each dimension and omit value when the state isn’t Score. A consumer reading {"type":"Missing","reason":"timeout"} can act accordingly. Defaulting to 0.0 or “unknown=false” invites misuse.

Teach callers to branch by type, not numeric checks

Documentation should show switch examples, not “if value is 0 then unknown.” This reduces coupling and preserves room for future states (e.g., “Contested,” “Deprecated”).

Audit conversion points with a line list

List every place where ScoreOrUnknown becomes a single number or a boolean. Audit these conversions periodically. If you discover accidental flattening, refactor to preserve states or add proper policy functions.

Accept that aggregation may return “no number”

Returning NaN or omitting a field is reasonable when inputs are fully unknown. Treat this as normal, not exceptional. UI can show “insufficient evidence” with counts; APIs can document this outcome clearly.

JSON serialization with a type field

A simple serializer sketch:

public Map<String, Object> toJson(ScoreOrUnknown s) {
    return switch (s) {
        case Score sc -> Map.of("type", "Score", "value", sc.value());
        case Missing miss -> Map.of("type", "Missing", "reason", miss.reason());
        case Unverifiable unv -> Map.of("type", "Unverifiable", "note", unv.note());
    };
}

Trade-offs and failure modes

Trade-offs

Transparency vs brevity: Returning types and reasons increases payload size but improves clarity. Favor clarity when ambiguity matters.
Strictness vs convenience: Throwing on invalid scores and disallowing defaults catches bugs early but may frustrate callers used to flexible shapes.
NaN vs explicit omission: NaN signals “no numeric value” but can be mishandled by consumers. Omitting a field or providing a separate state field avoids confusion.

Failure modes

“Silent flattening”: A downstream transforms unknowns to zero, likely out of habit. Catch this in contract tests.
“Enum drift”: If reason codes evolve, consumers break. Document codes and provide a safe default handling path.
“Partial measures hiding in averages”: An average of one numeric with three unknowns looks “complete” unless you also surface unknown counts.

Try it yourself

Refactor one DTO to embed a sealed state rather than a nullable numeric field. Add a type field in JSON. Update consumers to switch on type.
Write aggregation policies that return NaN or omit fields when inputs are fully unknown. Test behavior explicitly.
Add metrics that count unknowns and unverifiable states separately from numeric distributions.

Packaging Inference for Production: A Checklist for Shipping an Optimized-Model Service

Shubham Anandani — Thu, 23 Jul 2026 19:00:00 +0000

A model can be accurate and still be hard to operate if conversion is manual, artifacts are opaque, precision changes silently, or fallbacks have never been exercised. Production readiness is the process around the model as much as the model itself.

aceu-edge-infer is a modest inference demo, but I treat its packaging path as if another engineer will need to rebuild, inspect, and recover it. Its outputs remain illustrative, not evaluative of real people. This checklist is about making that kind of service repeatable.

Make model conversion reproducible

Keep conversion in a script or build step rather than a shell history. Record the source model hash, tool and runtime versions, input shapes, conversion options, and warnings. Use separate, reviewable configuration for FP32 and INT8 artifacts, and retain the conversion logs with the release build.

from pathlib import Path
import openvino as ov

source = Path("models/source.onnx")
output = Path("build/models/model_fp32.xml")
output.parent.mkdir(parents=True, exist_ok=True)

model = ov.convert_model(source)
ov.save_model(model, output)

This example shows the conversion step only. Production automation should also validate model inputs, run parity checks, record the tool version, and fail when expected artifacts are missing.

Version and identify the artifacts

Give model artifacts versions tied to the code and conversion configuration that produced them. Store IR XML and weights together, record hashes, and keep them immutable after release. If calibration or quantization changes, publish a new model version rather than overwriting a file called latest.

A release manifest can record the information operators need without embedding the model itself:

{
  "model_version": "<release-version>",
  "source_format": "ONNX",
  "runtime": "OpenVINO",
  "precision_artifacts": ["FP32", "INT8"],
  "device_policy": "CPU",
  "source_sha256": "<source-model-hash>",
  "conversion_config_sha256": "<config-hash>"
}

Replace the placeholders during the build. These are identifiers to calculate and record, not measured values to guess.

Disclose the execution path

Include the precision and device used in logs or response metadata. Where it makes sense for the product, provide a controlled option to route sensitive work through FP32. That small bit of transparency can make rollout analysis and incident response much faster. Keep the API contract stable and avoid exposing internal details that callers do not need.

Test fallbacks before a release

Simulate an unavailable optimized runtime and verify the intended behavior. A valid fallback should either return correct outputs on a supported slower path or fail clearly with a non-ready/unavailable state. It should not manufacture placeholder results or quietly claim the preferred precision.

If custom operators exist, test the fallback with representative inputs and confirm that the selected path is visible in logs. Document what operators or hardware are required for each execution mode.

Package the runtime deliberately

Use a multi-stage image where it keeps build tools out of the runtime. Run as a non-root user, keep the base image and dependencies maintained, copy only the application and model artifacts required at runtime, and provide a bounded health check.

# Illustrative Python service image; adapt paths and dependencies to your app.
FROM python:3.12-slim AS builder
WORKDIR /build
RUN python -m venv /venv
ENV PATH="/venv/bin:$PATH"
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.12-slim AS runtime
RUN useradd --uid 10001 --create-home appuser
WORKDIR /app
COPY --from=builder /venv /venv
COPY --chown=10001:10001 app/ ./app/
COPY --chown=10001:10001 models/ ./models/
ENV PATH="/venv/bin:$PATH" \
    PYTHONDONTWRITEBYTECODE=1
USER 10001
EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD python -c 'import urllib.request; urllib.request.urlopen("http://localhost:8000/health", timeout=2)' || exit 1
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Confirm that the chosen base image contains everything the service actually needs. The Docker health check should stay lightweight; configure a separate platform readiness check if model loading or a sample inference must gate incoming traffic.

Build, validate, and scan in CI

Use the same conversion scripts in local development and CI. Check that expected files exist, compare model outputs against a golden set, build the service image, and scan it before release. Make missing artifacts, failed parity checks, and scan failures visible release blockers. Keep exceptions owned and time-bounded.

Keep operational notes close to the code

Give the README short, findable sections for conversion, artifact versions, precision modes, fallback behavior, and hardware assumptions. Add an incident note describing what to inspect when latency or output parity changes, and point to the known-good artifact for rollback.

Trade-offs and failure modes

Trade-offs

Process rigor vs. prototype speed: Scripts and manifests take effort once and save time on the next rebuild.
More API metadata vs. smaller contract: Publish only what helps callers; keep additional operational detail in logs.
Strict readiness vs. faster first traffic: Waiting for model load and checks reduces false-green deploys.

Failure modes

“Mystery IR” files: Artifacts nobody can trace back to a source model or configuration.
Silent FP32 fallbacks: The service quietly runs a different precision than callers expect.
Unreviewed base image changes: A rebuild produces a different runtime than the one you tested.

Version the inputs and outputs, disclose the selected path, and exercise rollback before you need it.

Try it before your next release

Script FP32 and INT8 conversion and retain logs with immutable model artifacts.
Record source and configuration hashes in a release manifest.
Add actual precision/device metadata and a tested force-FP32 option if the product needs it.
Test missing-runtime and unsupported-operator behavior before launch.
Build, validate, and scan the same container image in CI that you intend to deploy.

Closing thought

Packaging inference for production is about repeatability, transparency, and safe recovery. When another engineer can recreate the model, identify the execution path, and trigger a tested fallback, the service is ready for more than a successful demo.

Designing for Other People’s Code: A Plugin API That Welcomes Contributions

Shubham Anandani — Mon, 20 Jul 2026 19:00:00 +0000

The best way to attract contributions is to make the path small, clear, and safe. Big, powerful extension APIs are intimidating and fragile. A plugin interface is easier to adopt when it has a small typed contract, a complete example, and clear isolation boundaries for contributed code.

The failure mode

You want contributions, so you design a rich, flexible plugin API. The first contributor struggles to understand how the parts fit together. Another contributor introduces side effects that break core behavior. You spend time triaging issues rather than merging useful additions. The fix is to narrow the contract and improve examples.

What I learned

Keep the interface tiny

Use a single method with a small, typed result. Avoid optional hooks and deep callback trees. If you need flexibility, let plugins implement it internally. Keep core expectations documented and enforced with tests.

Illustrative plugin contract

from dataclasses import dataclass
from typing import Literal, Protocol

@dataclass(frozen=True)
class EvidenceResult:
    status: Literal["present", "missing", "unverifiable"]
    note: str = ""

class EvidenceSource(Protocol):
    name: str
    def evaluate(self, profile: dict[str, object]) -> EvidenceResult: ...

Documentation-by-example beats long narratives

Write a short “Adding a plugin” doc that starts with a complete code example and a test. Follow with two variations that show common patterns (e.g., reading a field, combining small signals). Keep the words sparse and the code complete.

Sandboxing contributed code: practical guardrails

Run plugins within constraints:

Set a timeout per plugin evaluation.
Limit memory-intensive operations or external calls in the demo environment.
Validate types and restrict dangerous imports in plugin modules if possible.

A thread timeout is not a security sandbox: a host process cannot safely terminate arbitrary plugin code. For untrusted extensions, use a separate process or container with resource limits and restricted credentials, or load only trusted plugins.

Versioning and compatibility checks (keep them light)

Require plugins to declare supported interface versions and run contract tests. Keep the declaration simple, and make the CI failure message actionable (e.g., “Plugin supports 1.1.0; core is 1.2.0 — update SUPPORTED_VERSIONS”).

Golden paths and anti-patterns

Show five “golden path” examples contributors should follow:

Pure function: Read inputs, return EvidenceResult, no side effects.
Lightweight computation: Avoid heavy loops or large allocations.
Deterministic outputs: No random behavior or time-dependent outputs.
Typed result: Always return one of the three states with a note.
No external calls: For demo simplicity, avoid network calls.

If you allow external calls, define strict limits and document them clearly.

Error messages designed for contributors

When a plugin fails a contract test, the message should name the plugin, the failing expectation, and the fix. Prefer helpful failures over terse stack traces. Provide a “common issues” page with targeted guidance.

“Hello world” PR built into the docs

Include a numbered guide that results in a merged PR:

Create the plugin file.
Add a minimal test.
Run pytest -q.
Open a PR with the template.
Review the expected CI jobs and how to interpret them.
Review the merge expectations.

Trade-offs and failure modes

Trade-offs

Small interface vs expressiveness: Narrow contracts limit advanced features; they also reduce fragility and cognitive load. For small projects, this trade-off is worth it.
Sandboxing vs performance: Timeouts and thread isolation add overhead. Keep limits modest and configurable.
Documentation-by-example vs thorough reference: Examples speed onboarding; deep reference can come later if demand arises.

Failure modes

“Stealth side effects”: Plugins write to global state or files unexpectedly. Solution: sandbox and contract tests; make side-effect-free behavior a rule.
“Doc drift”: Examples fall behind reality. Solution: run example snippets in CI and fail when they don’t compile.
“Silent timeouts”: Sandboxing hides errors without surfacing enough context. Solution: attach structured error notes to EvidenceResult.

Try it yourself

Shrink your plugin interface to a single method that returns a small typed object.
Add a sandbox wrapper with timeouts and typed error handling. Run plugins through it in CI contract tests.
Write a “hello world plugin” guide with a copy-paste example and a minimal test, then merge a sample PR to validate the path.

Reproducible Java Builds: Pinning, Locking, and Clean-Room Verification

Shubham Anandani — Sun, 12 Jul 2026 19:00:00 +0000

I’ve seen Java builds succeed locally and differ in CI: transitive dependencies float, plugin versions advance, or caches hide changes. Reproducibility takes intention: pin versions, use lock files, and verify clean-room rebuilds. In a Java build, dependency locks and clean CI environments help reveal resolution drift before artifacts are released.

The failure mode

You set versions in pom.xml but leave transitive ranges unconstrained. Locally, a cached artifact hides a minor release; in CI, it resolves a new version. Behavior changes. The fix is not “rerun until green.” It’s making builds deterministic and verifying them under clean conditions.

What I learned

Pin dependencies and plugins explicitly

Use dependencyManagement to pin versions of critical dependencies and plugins. Avoid wildcard ranges. If you depend on a BOM (bill of materials), understand what it pins and add explicit versions for anything critical that the BOM leaves flexible.

Example

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter</artifactId>
      <version>5.10.2</version>
    </dependency>
    <!-- pin more -->
  </dependencies>
</dependencyManagement>

Use a lock mechanism to freeze transitive versions

A lock file captures resolved versions so CI doesn’t “discover” new transitive artifacts. Tools exist for Maven and Gradle that generate and enforce locks. The specifics depend on your chosen plugin; the principle is the same: generate once, commit, and enforce.

Generate the lock file locally (or in CI).
Commit it.
Configure the build to fail if resolutions differ from the lock.

Clean-room rebuild in CI

Build in an isolated environment with a cleared local repository. Verify that resolving dependencies succeeds strictly against your lock. Optionally run the build twice: once with the lock (expected success), and once with lock enforcement disabled to detect version drift. The second build should fail if drift occurred.

CI steps (illustrative)

- name: Clean local repo
  run: rm -rf ~/.m2/repository
- name: Verify dependency locks
  run: mvn -q -B clean verify -P enforce-lock
- name: "Clean room rebuild"
  run: docker run --rm -v "$PWD:/w" -w /w eclipse-temurin:21-jdk bash -lc "mvn -q -B clean verify -P enforce-lock"

Reproducible artifacts (timestamps and ordering)

Ensure JARs are reproducible: strip timestamps, stabilize entry ordering, and avoid embedding environment-specific paths. Many build tools support “reproducible build” flags. Enable them and verify artifact hashes are stable across clean rebuilds.

Digest references for external assets

If your build fetches external tools or base images (for integration tests, for example), reference them by digest. Tags are mutable; digests fix identity. The trade-off is manual refresh when security updates appear, which is worth it for determinism.

Automate updates safely

Use a dependency-update bot that proposes version bumps. Gate those PRs with tests and scanning. Accepting updates becomes explicit, and drift is no longer silent.

Document the “how to fix drift” playbook

When lock enforcement fails, the fix should be documented: regenerate the lock with your plugin, review changes, run tests, and commit. Avoid ad-hoc local resolutions, and keep the workflow consistent.

Trade-offs and failure modes

Trade-offs

Pins vs agility: Strict pins and locks slow updates but eliminate surprises. Use bots to keep pace safely.
Clean rooms vs speed: Clean rebuilds take longer. For CI, prioritize correctness over a few minutes of build time.
Digests vs tags: Digests provide determinism; tags ease maintenance. For production-critical assets, default to digests.

Failure modes

“Partial pins”: You pin direct deps but miss transitive ones. Locks solve this; without locks, drift leaks in.
“Plugin drift”: Build plugins advance silently. Pin plugin versions in pluginManagement.
“Non-reproducible JARs”: Differences in timestamps or ordering break hash equality. Turn on reproducible flags and verify.

Try it yourself

Add dependency and plugin pins in dependencyManagement and pluginManagement.
Integrate a lock mechanism, commit the lock file, and add an enforcement profile.
Run a clean-room rebuild in CI and compare the artifacts. Confirm artifact hashes match between runs.

Keys Don’t Belong in the Image: Secret Management for Credential Signing

Shubham Anandani — Sun, 12 Jul 2026 19:00:00 +0000

Signing keys are crown jewels in identity services. If they leak, attackers can mint forged credentials that look real. The easiest way to leak a key is to bake it into a container image or configuration file. Load signing keys at runtime from a managed secret store; keep private key material out of source files, build arguments, and image layers.

The failure mode

A contributor tests locally with a .env file containing a signing key. A sloppy Dockerfile copies everything under the project directory, including .env. CI builds the image; the key ends up in a layer. The image is pushed to a registry. Even if you rotate later, the leak is permanent in history.

What I learned

Secrets never live in source or image layers

Keep signing keys out of your repository and artifact layers. Use a managed secret store pattern to provide keys at runtime via secure mounts or platform-managed environment variables that never touch the image.

`.dockerignore` is a security control

Treat .dockerignore as part of your security posture. Explicitly ignore .env, credential files, test fixtures containing secrets, and local caches. Keep the build context as small as possible.

Runtime retrieval, not build-time embedding

Load keys at runtime from the secret store client library or a platform-provided mount. Fail readiness until the key loads. If the secret is missing, return clear errors and refuse to sign. Do not “fall back” to dummy keys in production. Reserve test keys for explicit non-prod builds.

Rotation: short lifetimes and multiple active keys

Signing keys should rotate regularly. The verifier should accept signatures from a small set of current keys, and the issuer should roll keys with overlap: publish the new key, start signing with it, and keep the old key valid for verification until the overlap window expires.

Audit and scanning: prevent accidental bake-ins

Add CI checks that scan images for secret patterns. Simple rules catch common mistakes (e.g., files named .env, PEM key headers). Block the build if found. Complement this with code scanning that flags dangerous COPY patterns.

Separate test and prod key handling

For demos, use explicitly marked test keys with sandboxed scopes. Never reuse test keys in environments accessible outside controlled demos. Label logs and status endpoints so it’s obvious which environment your verifier belongs to.

Minimize key surface: hardware-backed or managed services

Where possible, use hardware-backed key stores or provider-managed keys with restricted export. Keep application access tightly scoped to “sign” and “read public key.” The app should never be able to exfiltrate private key material.

Illustrative runtime secret loading

def load_signing_key(secret_store, key_id: str) -> bytes:
    key = secret_store.read(key_id)
    if not key:
        raise RuntimeError("signing key unavailable")
    return key

# Load keys from a managed store at runtime. Never copy key material
# into source, build arguments, container layers, or sample configuration.
# Keep readiness false until the signing dependency is ready.

Example `.dockerignore`

.env
*.pem
__pycache__/
*.pyc
.git/
node_modules/
tests/fixtures/secrets/

Example Dockerfile pattern

FROM python:3.12-slim AS runtime
WORKDIR /app
COPY pyproject.toml poetry.lock ./
RUN pip install --no-cache-dir poetry && poetry install --no-root
COPY --chown=10001:10001 app ./app
USER 10001
EXPOSE 8000

Trade-offs and failure modes

Trade-offs

Runtime dependency vs build independence: Secret store clients add runtime requirements. The gain is eliminating baked-in risk.
Rotation complexity vs safety: Overlapping keys complicate issuers and verifiers. The gain is smooth migration.
Strict readiness vs availability: Refusing to start without keys prevents undefined behavior. Availability dips are better than silent mis-signing.

Failure modes

“COPY .”: Blindly copying the entire source tree into the image. Fix with .dockerignore and explicit COPY.
“Fallback key”: Using a dummy key in production when secret load fails. Fix with hard failures and improved observability.
“Exportable private keys”: Allowing the app to export private keys. Fix with hardware-backed or provider-managed keys.

Try it yourself

Add .dockerignore entries for secrets and verify your build context (run docker build --no-cache and inspect the logs).
Use strict readiness that fails until keys load from a managed store. Test rotation: accept signatures from two keys during an overlap window.
Add CI scans that fail on secret-like files in images. Track and eliminate false positives carefully.

Deploying Identity Services Without a Server to Babysit

Shubham Anandani — Thu, 25 Jun 2026 19:00:00 +0000

Running identity-adjacent services on a scale-to-zero container platform can be delightful: no server to babysit, external HTTPS ingress, and idle billing that doesn’t punish quiet periods. With scale-to-zero containers, quiet periods can reduce idle usage. The trade-off is that the first request after an idle period may be slower, so measure that cold path against the latency needs of the service.

Identity workloads, however, bring constraints: some callers expect predictable latency, and some flows require warm caches or keys ready in memory. The trick is deciding where scale-to-zero helps and where “always on” wins.

The failure mode

You deploy a credential verifier that scales to zero. The first request after an idle period may be much slower than warm requests. A downstream system times out, retries, and amplifies load just as the platform is warming. Worse, your verifier loads keys and trust lists at startup, so the warming step is non-trivial. You saved on idle billing but created unpredictable tails.

What I learned

Cold start budget: measure and design around it

Measure cold starts: container pull, runtime initialization, key load, trust list load, and framework boot. If your end-to-end verification flow includes out-of-process checks (e.g., privacy-preserving revocation lookups), include those too. Decide whether your SLA tolerates the tails; if not, keep a minimum warm replica.

Warm critical paths with lazy loading and caches

Avoid monolithic startup. Load credential-signing keys via a managed secret store, but defer non-critical data until requested. Cache trust lists in memory and refresh asynchronously. Keep proof verification code hot by executing a tiny “self-check” during startup.

Set min replicas for latency-sensitive endpoints

If your platform supports minimum replicas, keep one verifier instance warm. Scale additional instances on demand. This hybrid approach preserves predictable latency while retaining cost controls.

Health, readiness, and the “thin ready” trap

Identity verifiers shouldn’t mark “ready” until critical dependencies (keys, trust lists) are present and a test proof passes. A “thin ready” (bare process up) can route traffic to a half-initialized instance, increasing failure rates.

Scale rules: event triggers vs queue length

If you use event-driven scale, ensure triggers reflect verifier load. Queue length or request rate are better signals than raw CPU in a verifier, since cryptographic checks are sporadic and short. Use conservative ramp-up to avoid stampedes during traffic bursts.

Idle billing: cost vs safety

Scale-to-zero saves money during periods of inactivity. In identity systems, weigh this against the cost of false timeouts and retries. For certain flows (e.g., login or checkout proofs), unpredictable tails are more expensive than idle replicas.

Pipeline hygiene: small image, quick pull

Use multi-stage builds, slim bases, and .dockerignore to keep images small. The smaller the image, the faster the cold start. Avoid compiling dependencies at startup; freeze them in the image. Keep secrets out of layers entirely (next article).

Illustrative configuration

# Generic container-app.yaml structure
name: identity-service
ingress:
  external: true
  targetPort: 8000
template:
  containers:
    - image: your-registry/identity-service:tag
      resources:
        cpu: 0.5
        memory: 0.5Gi
  probes:
    liveness:
      httpGet: { path: /health, port: 8000 }
    readiness:
      httpGet: { path: /ready, port: 8000 }
  scale:
    minReplicas: 1 # Keep one warm replica
    maxReplicas: 10
    rules:
      - name: http-requests
        http: { metadata: { concurrentRequests: "50" } }

Trade-offs and failure modes

Trade-offs

Cost vs predictability: Scale-to-zero cuts idle spend but risks unpredictable tails. Hybrid min replicas often balance both.
Strict readiness vs fast green: Stricter readiness delays routing but avoids half-initialized failures. Bias toward strict in identity contexts.
Lazy load vs startup completeness: Deferring non-critical data speeds boot but adds first-request work. Choose wisely.

Failure modes

“Thin ready”: Traffic routed to instances without loaded keys or trust lists. Fix readiness to validate critical paths.
“Stampede”: A traffic surge triggers too many replicas and cache thrash. Fix scale rules and backpressure.
“Oversized image”: Cold starts dominated by image pulls. Fix Docker hygiene.

Try it yourself

Measure the cold start path and identify high-cost steps. Record cold-start and warm-request latency as separate measurements.
Add a minimum warm replica and track tails. Compare p95 across scale-to-zero vs hybrid.
Implement readiness that runs a tiny proof self-check and confirms secret load before returning ready.

Null Isn’t False: Building Fair Credential Verifiers

Shubham Anandani — Sat, 30 May 2026 19:00:00 +0000

One of the subtle but damaging patterns in identity systems is treating null as false. If a credential lacks a field, or a proof is absent, some code paths flip a boolean to false and move on. In verification, this collapses “we don’t know” into “disproven.” The difference matters: missing evidence isn’t proof of falsehood.

The failure mode

A verifier expects a proofOfX field. The credential arrives without it. The code sets proofOfX=false. A downstream gate denies access. Later, it turns out proofOfX wasn’t required for this flow, or the holder didn’t have a way to request it yet. The deny was based on an absence, not a disproven claim.

What I learned

Model states, not booleans

Replace booleans with intent-rich types. For a given proof, consider states like these:

Present: The evidence arrived and checks out.
Missing: The evidence was not provided.
Expired: The evidence was valid but is past its lifetime.
Revoked: The issuer withdrew the credential.
Unverifiable: The evidence can’t be checked (e.g., failed binding).
Invalid: The evidence is malformed or has a bad signature.

This simple taxonomy avoids flattening all “not present” into “false.”

Exhaustive decision logic at boundaries

At the verifier boundary, use exhaustive switches over the state. Force downstream callers to handle each branch. If your language supports pattern matching, lean on it to eliminate default fall-through behaviors.

Treat absence as an opportunity to request or fall back

If a required field is missing, decide whether to:

Prompt the holder to supply it (if applicable).
Proceed with reduced assurance and log the state.
Deny the request explicitly as “unverifiable,” not “invalid.”

The right action depends on your policy and context; the key is keeping “unverifiable” distinct.

Make “invalid” a narrow, technical category

Invalid should mean “structured wrong,” “bad signature,” or “contradiction.” It shouldn’t include “not provided,” “not bound,” or “not present yet.” Narrow “invalid” ensures you don’t over-penalize users for the system’s constraints.

Propagate state through APIs and UX

Expose the state in API responses: include status: "unverifiable" with a short note. Avoid returning false or 0 as a sentinel for “missing.” In UX, explain that more evidence is needed or that a different path is available.

Beware implicit type coercions

JSON, databases, and ORMs often coerce nulls to zero or false. Audit these boundaries. Ensure your serializers and persistence layers preserve state labels rather than defaulting values.

Test for fairness: counterfactuals

Put fairness into tests. For example: if proofOfX is missing, does the system deny or ask for more evidence? Are there alternative flows? Keep tests that assert the difference between “unverifiable” and “invalid.”

Explicit verification outcomes

from dataclasses import dataclass
from typing import Literal

Status = Literal["accepted", "unverifiable", "invalid"]

@dataclass(frozen=True)
class FieldCheck:
    name: str
    status: Status
    note: str | None = None

Trade-offs and failure modes

Trade-offs

More state complexity vs simplicity: Explicit states add a little code. The clarity and fairness gains are worth it.
UX friction vs silent denial: Asking for more evidence can add steps. Silent denials are worse. Balance friction with guidance.
Logging granularity vs privacy: Notes improve debugging; ensure they contain no sensitive data.

Failure modes

“Hidden coercion”: Tooling collapses null to false. Solution: audit boundaries and enforce state labels.
“Catch-all invalid”: Development shortcuts treat everything negative as invalid. Solution: write exhaustive switches and linters.
“Unverifiable loop”: Repeated prompts for evidence without alternative paths. Solution: define fallback policies clearly.

Try it yourself

Replace boolean checks for critical credential fields with stateful outcomes (“accepted,” “unverifiable,” “invalid”).
Expose the state in your verifier’s API. Track how often “unverifiable” occurs and address UX with prompts or fallbacks.
Add tests that assert denials only occur for “invalid,” not “unverifiable.”

Docker in CI: The Real Cost of Docker-in-Docker

Shubham Anandani — Sat, 23 May 2026 19:00:00 +0000

Docker-in-Docker (DinD) can make CI feel simple: start a job, build an image, run container-based tests. The convenience comes with a real isolation decision. Privileged DinD can weaken the boundary around the runner; mounting the host Docker socket can give a build step powerful control over the host daemon.

Teams still choose these patterns because they support familiar workflows. The important thing is to make the choice explicit, restrict which code can use it, and avoid a “green” result when container tests never ran.

First, know which daemon the job is using

“Docker in CI” does not always mean DinD. Some runners expose a Docker daemon to the job; DinD starts a separate Docker daemon inside a service container. A mounted /var/run/docker.sock is a third pattern: the job’s Docker CLI talks to the host daemon. These setups have different isolation properties. Document the runner architecture before relying on it.

Verify the daemon before running tests

Make readiness an explicit step. If the daemon is missing or unresponsive, stop the job before it reports container-dependent tests as successful:

# Run only on a runner configured to provide Docker access.
set -eu
docker version
docker info

IMAGE="aceu-trust-demo:${GITHUB_SHA:-local}"
docker build --tag "$IMAGE" .
docker run --rm "$IMAGE" pytest -q

For an actual DinD service, the job also needs to wait for that service’s daemon to become available. A fixed sleep is brittle; use a bounded readiness loop and fail with a clear message if the daemon never responds.

Do not silently skip container-dependent tests

If the daemon is a prerequisite, the test should fail when Docker is unavailable. Avoid code that catches every exception and quietly returns a passing or skipped result in a required CI job:

import subprocess

def docker_available() -> bool:
    try:
        subprocess.run(
            ["docker", "info"],
            check=True,
            capture_output=True,
            text=True,
            timeout=10,
        )
        return True
    except (FileNotFoundError, subprocess.CalledProcessError, subprocess.TimeoutExpired):
        return False

def test_containerized_health_check_requires_docker():
    assert docker_available(), "Docker daemon is required for this test"
    # Continue with the containerized test flow.

Tag Docker-dependent tests so developers can distinguish them from pure unit tests, but keep them required in the CI path that claims to validate the container.

Choose the access pattern with eyes open

Privileged DinD: Familiar and flexible, but grants elevated capabilities to the service container. Restrict it to trusted workflows and isolate the runner.
Host socket mount: Avoids starting another daemon, but the mounted socket can let job code control the host Docker daemon. Treat access as highly privileged.
Daemonless or remote builders: Can reduce direct daemon exposure in some environments, but require setup and may change the build workflow.

In every case, pin build images, keep credentials scoped, avoid running untrusted pull-request code on privileged self-hosted runners, and clean up jobs so containers and volumes do not leak into later runs.

Watch for isolation leaks and flaky runners

Look for unexpected host mounts, files written outside the workspace, orphaned containers, and daemon failures. Runner fleets can have transient problems. A documented single retry can filter a brief infrastructure hiccup, but repeated failure should remain visible and investigated, not retried until a broken test turns green.

Trade-offs to discuss with the team

Speed vs. isolation: DinD is familiar; stricter alternatives can require more setup.
Fail closed vs. ergonomics: Blocking on daemon failure catches false greens but can be frustrating when runner health is poor. Give contributors a clear error and retry path.
Socket mount vs. privileged mode: Neither is a free isolation boundary. Limit trusted code and runner scope for either design.

Try it in your CI

Write down whether jobs use host Docker, a mounted socket, or a separate DinD service.
Add a daemon readiness check before any container-dependent test.
Make those tests fail if Docker is unavailable; do not silently skip them.
Evaluate a daemonless or remote builder against your runner threat model.
Document when one retry is appropriate and when repeated failure needs investigation.

Closing thought

DinD can be pragmatic, but it should never be invisible. Verify the daemon, make tests fail closed, and choose an isolation pattern that matches what the CI job is trusted to do.

Flaky Tests Are a Concurrency Bug: Fixing Shared State Under Parallel Execution

Shubham Anandani — Fri, 15 May 2026 19:00:00 +0000

I’ve watched teams chase “test runner bugs” while the real culprit was design. Flakiness is often a concurrency issue: shared mutable state under parallel execution. JUnit 5 can run tests concurrently, so fixtures that share mutable state can make failures appear intermittent. Creating isolated data per test makes the behavior easier to reproduce and diagnose.

The failure mode

You enable parallel test execution and see intermittent failures: “record not found” or “unexpected duplicate.” You re-run and it passes. Blaming the test runner is easy. The problem is shared state: two tests reading or writing the same fixture or relying on an implicit order.

What I learned

Default to per-test fixtures

Use per-test initialization to avoid shared mutable state. In JUnit 5, keep your test instance lifecycle at PER_METHOD and recreate fixtures for each test. If the fixture is expensive, consider a template with parameterization that still isolates state.

Example setup

import org.junit.jupiter.api.*;

@TestInstance(TestInstance.Lifecycle.PER_METHOD)
class EvidenceServiceTest {
    private InMemoryStore store;
    private EvidenceService service;

    @BeforeEach
    void init() {
        store = new InMemoryStore(); // new store per test
        service = new EvidenceService(store);
        store.seedProfile("alice", syntheticProfileAlice());
    }

    @Test
    void returnsMissingWhenTimeout() {
        // ...
    }

    @Test
    void returnsUnverifiableOnExceptions() {
        // ...
    }
}

Avoid static mutable fields, especially in helpers

Static caches and helpers make tests faster locally but brittle in parallel. If you truly need a cache, scope it per test, or guard it with thread-safe constructs and clear it explicitly. Better: don’t cache at all in tests unless you benchmarked the need.

Make isolation visible with name-bound fixtures

If a test seeds data, bind it to a unique key per test. Use random UUIDs or test names in keys to prevent accidental cross-test reuse. With Testcontainers, create per-test containers when state isolation is critical; share containers only for read-only tests.

Parallel execution deserves explicit design

JUnit 5 lets you run tests in parallel. That doesn’t mean every test should be parallel. Annotate classes that require single-thread execution, but treat that as a last resort. Prefer making tests parallel-safe by design.

JUnit configuration (illustrative)

junit.jupiter.execution.parallel.enabled = true
junit.jupiter.execution.parallel.mode.default = concurrent
junit.jupiter.execution.parallel.mode.classes.default = concurrent

Deterministic time and waiting

Tests that sleep and “hope the system is ready” fail under parallel runs. Replace sleeps with explicit synchronization: await a condition, poll with a small backoff, or use latches. Keep timeouts small and deterministic.

Embrace “given-when-then” with isolated builders

Build input data per test with dedicated builders. Don’t reuse a mutable “default profile” object across tests; copy or reconstruct it. Records help: immutable inputs prevent accidental mutation.

Diagnose with logging and seeds

When a test fails intermittently, print seeds and keys that identify data. If you see the same key in two tests, you found shared state. If you see non-deterministic ordering in a collection, sort inputs or assert set equivalence rather than list order.

Per-test container with unique data

class StoreTests {
    private PostgreSQLContainer<?> database;

    @BeforeEach
    void setUp() {
        database = new PostgreSQLContainer<>("postgres:alpine")
            .withDatabaseName("test_" + UUID.randomUUID())
            .withUsername("user")
            .withPassword("test-only");
        database.start();
    }

    @AfterEach
    void tearDown() {
        database.stop();
    }
}

Trade-offs and failure modes

Trade-offs

Isolation vs speed: Per-test fixtures are slower than shared ones. Optimize later: start with correct behavior and only share read-only fixtures.
Parallelism vs determinism: Parallel runs surface concurrency bugs but may require more careful test design. The benefits outweigh the cost.
Container lifecycle vs developer ergonomics: Per-test containers are robust but slower. Consider class-level containers for read-only tests with clear resets.

Failure modes

“Hidden globals”: A helper modifies a static map. Under parallel execution, tests interleave and fail intermittently.
“Order assumptions”: Tests rely on iteration order of sets or maps; parallel runs expose different orders.
“Implicit sleeps”: Tests use fixed sleeps; faster or slower environments cause out-of-order expectations.

Try it yourself

Switch to the PER_METHOD lifecycle and remove static mutable fields in tests. Add unique keys per test to seed data. Enable parallel execution and watch for failures that indicate hidden shared state.
Replace sleep-based readiness with explicit condition checks. Add timeouts and backoff policies.
Document which tests are parallel-safe and why; make non-parallel tests the exception and note the reason.

CPU-Only, By Design: Building an Edge-AI Service Without Assuming Accelerators

Shubham Anandani — Fri, 15 May 2026 19:00:00 +0000

Not every deployment target has a dedicated accelerator. In many environments, the only safe assumption is a general-purpose CPU. Treating that as a deliberate design constraint makes the service easier to deploy, explain, and operate.

aceu-edge-infer is a small CPU-first inference demo with a documented OpenVINO runtime path. Its ACE-U outputs are illustrative, not a validated assessment of people. The design lesson is broader: state the hardware contract and make the service’s behavior when that contract is not met explicit.

Document the hardware contract

Say which device is required and what is optional. If CPU-only execution is supported, describe the expected model format, available runtime, resource needs, and what performance behavior users should plan for. If an accelerator is optional, list supported devices and the path selected when one is missing.

Make device selection explicit

For an OpenVINO model intended for CPU execution, specify the device in the compile call rather than relying on a default selection:

import openvino as ov

core = ov.Core()
model = core.read_model("models/aceu_ir.xml")
compiled_model = core.compile_model(model, "CPU")

Test the exact runtime package and operating system you plan to ship. If startup cannot load the model or compile it for CPU, do not report the service as ready.

Distinguish a fallback from a failure

A fallback is a real, tested alternative execution path. It may be a different model artifact, a portable runtime, or a slower implementation that produces valid outputs. If none exists, the honest response to a missing runtime is a clear startup failure or an unavailable response, not placeholder scores or a “fallback” label that hides the problem.

Expose execution metadata that helps operators understand the path without leaking environment details:

execution_info = {
    "device": "CPU",
    "precision": "INT8",
    "fallback_used": False,
}

In a real service, derive these values from the compiled model and request path; do not hard-code them when the runtime can choose a different path.

Degrade predictably on constrained hardware

Assume memory and CPU shares may be limited. Measure the model’s memory footprint and end-to-end latency on the target class of device. Start with conservative concurrency; more threads do not automatically mean better p95 latency. If the service supports it, adjust batch size, request timeout, or concurrency by deployment profile, and document the effect.

Do not silently lower quality when the machine is under pressure. If a request is rejected, deferred, or routed to a different precision, make the behavior observable and keep the response contract clear.

Separate startup, readiness, and liveness

Startup: Load the model and confirm the selected CPU runtime can compile it.
Readiness: Confirm the service can complete the critical inference path before it receives traffic.
Liveness: Use a cheap check for a process that is stuck, not an expensive inference on every probe.

A stricter readiness check may delay the first “ready” signal. That is preferable to routing requests to a service that has not loaded its model. Keep checks bounded so probes do not become a source of load.

Keep operational assumptions beside the code

Add a “Hardware assumptions” section to the README and link it from deployment instructions. Include supported devices, runtime versions, precision choices, resource settings, fallback behavior, health endpoints, and a short way to verify the selected execution mode. The next engineer should not have to infer these from source code.

Trade-offs and failure modes

Trade-offs

CPU portability vs. latency: A CPU path broadens where the service can run, but may not meet a workload’s latency target. Measure before promising an SLA.
Optional accelerators vs. maintenance: Each extra path adds test and support cost; add only devices the product needs.
Strict readiness vs. quick deployment: Waiting for a successful model load delays traffic, but avoids a false-green service.

Failure modes

Assumed hardware: The service expects a device that is not present.
Tight retry loops: Device selection is retried repeatedly instead of failing clearly.
Undocumented requirements: Hardware needs live only in someone’s head or in the source.

Provide a clear failure state and a controlled recovery path instead.

Try it yourself

Write the CPU and optional accelerator requirements in your README.
Expose the actual device and precision selected for each execution path.
Simulate a missing optimized runtime and verify that the service fails clearly or uses a genuine tested fallback.
Measure memory and latency under representative CPU limits before selecting concurrency defaults.

Closing thought

Designing for CPU-only execution is not a claim that CPU is always enough. It is a way to make assumptions visible, provide a credible fallback where one exists, and keep the service predictable on the hardware it supports.

Virtual Threads Changed My Mental Model: Practical Lessons From I/O Fan-Out

Shubham Anandani — Mon, 13 Apr 2026 19:00:00 +0000

Virtual threads changed how I design I/O fan-out in Java services. As an engineering manager who grew up with fixed thread pools, queue sizing, and saturation metrics, I had muscle memory: “pick a pool size, tune it, protect it.” With virtual threads, I can treat blocking I/O more like straightforward code again, without tying throughput to a small pool.

The failure mode

A caller triggers N downstream calls per request (fan-out). With a fixed pool, saturation appears quickly under spikes; with virtual threads, spikes are absorbed but not eliminated. If you translate “we can spawn thousands of threads” into “we don’t need back pressure,” you’ll rediscover failures, just in different places.

What I learned

Think “task-per-thread” for blocking I/O, not “pool-per-service”

Virtual threads make “one virtual thread per blocking task” feasible. You can write linear code for a downstream call and not contort it into callbacks just to avoid blocking. That simplifies failure handling and resource cleanup.

Example fan-out

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    List<Callable<EvidenceResult>> tasks = sources.stream()
        .map(source -> (Callable<EvidenceResult>) source::fetchEvidence)
        .toList();
    List<Future<EvidenceResult>> futures = executor.invokeAll(tasks);
    List<EvidenceResult> results = new ArrayList<>(futures.size());
    for (Future<EvidenceResult> future : futures) {
        results.add(future.get());
    }
    return aggregate(results);
}

This reads like blocking I/O because it is, but with virtual threads, the scheduler multiplexes them efficiently.

Back pressure still matters

If downstream services or data sources choke under spikes, virtual threads won’t magically fix it. The caller can spin up many virtual threads, but the destination still has limits. You need timeouts, rate limits, and circuit breakers. You also need to avoid accidental fan-in (e.g., mass aggregation that blocks on slowest responders indefinitely).

CPU-bound work belongs elsewhere

Virtual threads help with blocking I/O, not CPU-heavy tasks. If a task saturates CPU, the scheduler can’t help. You need to bound parallelism with a platform-appropriate mechanism (e.g., a limited executor or structured concurrency approach) to avoid oversubscription.

Failure semantics are simpler when code is linear

Exception handling in “straight-line” code is clearer than in callback-based designs. You still need to decide whether partial evidence returns a partial result (with Missing/Unverifiable states) or you fail the whole request. Virtual threads don’t make that decision; they just make the code easier to read.

“Thousands of threads” doesn’t mean “no limits”

Virtual threads are cheap, but not free. Sockets, file descriptors, and memory buffers are finite. The OS still enforces resource ceilings. Guard your fan-out with sensible limits: per-request caps, per-destination timeouts, and global safety checks.

Observability shifts upstream

With fixed pools, saturation appears as queue wait time. With virtual threads, saturation shifts to downstream latency and timeouts. Make sure your metrics capture per-destination latency percentiles and error rates. A spike in virtual-thread creation can be fine if destinations are healthy; it’s not fine if percentiles explode.

Test under synthetic spike and tail latency

I haven’t yet measured performance between virtual threads and a fixed pool for the demo. What I do measure is behavior under artificial spikes: do timeouts fire? Does the aggregation return timely partial results with Missing/Unverifiable? Tests simulate slow destinations and verify we don’t hang.

Timeout per downstream call

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    Future<EvidenceResult> future = executor.submit(source::fetch);
    try {
        return future.get(timeout.toMillis(), TimeUnit.MILLISECONDS);
    } catch (TimeoutException timeoutError) {
        future.cancel(true);
        return EvidenceResult.unavailable("timeout");
    }
}

Trade-offs and failure modes

Trade-offs

Simplicity vs explicit limits: Virtual threads reduce boilerplate, but you still must implement back pressure. Silent defaults can mask saturation until it’s too late.
“Everything virtual” vs CPU realities: Virtual threads help with I/O. For CPU-bound work, a bounded executor or workload partitioning is safer.
Observability differences: You lose fixed-pool queue metrics and gain per-destination latency metrics. Update dashboards and alerts accordingly.

Failure modes

“Soft hangs”: Aggregation waits on the slowest responder forever. Add timeouts and partial-return logic.
“Resource leaks”: Thousands of virtual threads keep sockets open longer than intended. Validate resource cleanup paths.
“Oversubscription”: CPU-heavy tasks in virtual threads degrade the whole process. Bound CPU parallelism explicitly.

Try it yourself

Replace a fixed thread pool fan-out with newVirtualThreadPerTaskExecutor() and add per-destination timeouts. Observe behavior under synthetic spikes.
Add aggregation logic that treats timeouts as Missing and downstream errors as Unverifiable. Verify exhaustive handling with pattern matching.
Measure throughput and p95 latency in a controlled environment to inform whether virtual threads help your workload.

DEV Community: Shubham Anandani

Revocation Is the Hard Part

The failure mode

What I learned

Understand the revocation design space

Status list (offline)

Online status check

Holder stapling

Short-lived credentials:

Privacy-preserving lists: batch and compress

Stapling shifts “phone home” to holder flow

Short-lived credentials reduce time at risk

Model cache freshness and failure modes

Avoid per-ID URLs in logs

Distinguish revocation from expiry and audience

Illustrative status-list freshness check

Trade-offs and failure modes

Trade-offs

Failure modes

Try it yourself

Further reading

Designing for Partial Data: Distinguishing “We Don’t Know” From “False”

The failure mode

What I learned

Model the states as a sealed type

Keep partial states in the domain layer, not just at the edges

Policy example

Propagate uncertainty deliberately

Make unknown-handling policies explicit and testable

Resist “default values” in DTOs

Teach callers to branch by type, not numeric checks

Audit conversion points with a line list

Accept that aggregation may return “no number”

JSON serialization with a type field

Trade-offs and failure modes

Trade-offs

Failure modes

Try it yourself

Further reading

Packaging Inference for Production: A Checklist for Shipping an Optimized-Model Service

Make model conversion reproducible

Version and identify the artifacts

Disclose the execution path

Test fallbacks before a release

Package the runtime deliberately

Build, validate, and scan in CI

Keep operational notes close to the code

Trade-offs and failure modes

Trade-offs

Failure modes

Try it before your next release

Closing thought

Further reading

Designing for Other People’s Code: A Plugin API That Welcomes Contributions

The failure mode

What I learned

Keep the interface tiny

Illustrative plugin contract

Documentation-by-example beats long narratives

Sandboxing contributed code: practical guardrails

Versioning and compatibility checks (keep them light)

Golden paths and anti-patterns

Error messages designed for contributors

“Hello world” PR built into the docs

Trade-offs and failure modes

Trade-offs

Failure modes

Try it yourself

Further reading

Reproducible Java Builds: Pinning, Locking, and Clean-Room Verification

The failure mode

What I learned

Pin dependencies and plugins explicitly

Example

Use a lock mechanism to freeze transitive versions

Clean-room rebuild in CI

CI steps (illustrative)

Reproducible artifacts (timestamps and ordering)

Digest references for external assets

Automate updates safely

`.dockerignore` is a security control

Example `.dockerignore`