← Back to homepage
Writing & Research

Ideas tested against engineering practice

This archive brings together my published articles and research. Each entry includes a short companion note about the problem behind the work, what I learned from it and why the idea remains useful.

Browse by theme

Advertising, Privacy & TrustDistributed Systems & Cloud InfrastructureExperimentation & Applied Mathematics
Theme

Advertising, Privacy & Trust

How measurement, personalization and AI can remain useful while respecting privacy and earning customer trust.

See related engineering interests →
Beyond Compliance: Designing Systems That Earn Customer Trust — CSO Online
Privacy & Security

Beyond Compliance: Designing Systems That Earn Customer Trust

CSO Online

Why privacy and customer trust must be enforced across distributed systems, data flows, caches and AI workflows—not treated only as a compliance checklist.

I wrote this piece because privacy programs are often described through policies, controls and deadlines, while the difficult engineering work happens much deeper in the system. A customer request may touch ordering records, subscriptions, digital content, indexes, queues, archives and analytics data. That means trust depends on how reliably the entire data path honors the customer’s intent—not merely on whether a request entered a compliance workflow. The idea I would emphasize even more today is that privacy behavior should be observable in the same way as availability or latency. Teams need to know which systems acknowledged an obligation, which actions completed, where retries are occurring and whether derived data remains consistent. This becomes especially important as AI systems create new data flows and reuse information in ways that are not always obvious from the original product interface. Privacy by design is therefore less about adding a gate and more about building a dependable, auditable system whose behavior can be explained to customers and operators.

Read the original on CSO Online ↗
What Search and Recommendation Systems Taught Me About Enterprise AI — VKTR
Enterprise AI

What Search and Recommendation Systems Taught Me About Enterprise AI

VKTR

Lessons from large-scale search and personalization on retrieval, data freshness, experimentation, feedback loops, privacy and operating trustworthy enterprise AI.

The article grew from a pattern I have seen repeatedly: a promising model is only one part of a useful production system. Search and recommendation platforms taught engineering teams to care about retrieval quality, changing customer interests, fresh catalog data, low-latency serving, controlled experimentation and feedback that does not simply reinforce what is already popular. Enterprise AI is now rediscovering many of the same lessons. A system can produce an impressive answer in isolation and still fail if its source data is stale, its retrieval path is weak or no one can determine whether the answer helped. What continues to interest me is the infrastructure around the model. How quickly can new evidence become available? How do teams test a change without confusing novelty with lasting value? How do less-known items receive a fair opportunity to be discovered? These questions connect recommendation engineering with modern AI systems and keep the discussion grounded in customer usefulness rather than model capability alone.

Read the original on VKTR ↗
Theme

Distributed Systems & Cloud Infrastructure

Systems, storage practices and operating choices behind reliable infrastructure at scale.

See related engineering interests →
Ransomware-Resilient Storage: The New Frontline Defense in a High-Stakes Cyber Battle — InfoQ
Storage & Security

Ransomware-Resilient Storage: The New Frontline Defense in a High-Stakes Cyber Battle

InfoQ

Why recovery architecture, immutability and storage-layer defenses have become central to modern cybersecurity and resilient infrastructure.

Security discussions often concentrate on preventing an attacker from entering a system. I wanted this article to examine the equally important question of what happens after prevention fails. Storage is where the organization’s operational memory lives, so recovery cannot be treated as a backup job that sits outside the architecture. Immutability, isolated recovery paths, access separation and routine restoration tests all matter because a backup that cannot be trusted or restored under pressure is not a recovery strategy. The broader engineering lesson is that resilience must be practiced. Teams should know which data is essential, how dependencies affect restoration order and how long a usable recovery actually takes. Those answers rarely emerge from a single tool. They come from system design, operational ownership and repeated exercises that reveal assumptions before an incident does. I continue to view ransomware resilience as a distributed-systems problem as much as a security problem: failures propagate through dependencies, and recovery succeeds only when the full path has been designed and tested.

Read the original on InfoQ ↗
AI/ML-Based Storage Optimization — DZone
AI & Cloud

AI/ML-Based Storage Optimization

DZone

A practical approach to predicting cloud storage cost and recommending configurations from workload behavior.

Storage optimization is a useful example of where machine learning can assist engineering judgment without replacing it. The model in this article uses familiar signals—object size, access frequency, recency and storage class—to forecast cost or recommend a tier. The interesting part is not the choice of algorithm. It is the work required to make the input trustworthy and the recommendation safe to apply. Billing exports, access logs and object metadata rarely arrive in one clean form, and access patterns can change because of seasonal demand or a new product workflow. I would now place even more emphasis on guardrails: show the recommendation first, measure its effect, and keep a reliable rollback path before allowing automatic movement. The same principle applies broadly to operational AI. Start with a decision that people already make, identify evidence that improves it, and introduce automation in stages. A modest model connected to good data and clear controls is often more useful than a sophisticated model operating without context.

Read the original on DZone ↗
Benchmarking Storage Performance with Python — DZone
Performance Engineering

Benchmarking Storage Performance with Python

DZone

A hands-on method for examining latency and throughput instead of relying on generic cloud-performance assumptions.

Cloud storage is easy to provision, which can create the impression that its performance is equally predictable. In practice, latency and throughput change with object size, concurrency, region, network conditions and the storage class being used. I wrote this tutorial to make those differences measurable with a small amount of Python rather than leaving teams to reason from broad service descriptions. The deeper point is that a useful benchmark must resemble the workload it is meant to inform. A test built from tiny sequential reads tells us little about a system that handles large parallel transfers, and a short run may hide throttling or variance that appears over time. I would pair these scripts with percentile latency, repeated runs and clear documentation of the test environment. Benchmarks should not produce one universal number; they should reduce uncertainty around a specific design decision. That approach makes performance testing useful earlier, before assumptions become expensive architectural constraints.

Read the original on DZone ↗
Automating Storage Tiering and Lifecycle Policies in AWS S3 — DZone
Cloud Automation

Automating Storage Tiering and Lifecycle Policies in AWS S3

DZone

Using Python and Boto3 to turn storage-management policy into repeatable automation.

Lifecycle policies look simple on paper: identify data that is no longer frequently used and move it to a more appropriate storage class. The operational challenge is that age alone is rarely enough. Retention rules, restore time, request patterns and downstream dependencies all influence whether a transition is safe. This article uses Python and Boto3 to show how policy can become repeatable automation, but the enduring lesson is to make the policy explainable. Operators should be able to see why an object moved, what rule applied and how to reverse the decision if the workload changes. I would also treat policy changes like software releases: review them, test them against representative data and observe their effects before broad rollout. Automation is most valuable when it removes repetitive work while preserving judgment at the points where risk is highest. That balance turns lifecycle management from a collection of manual cleanups into a dependable platform capability.

Read the original on DZone ↗
Securely Accessing and Managing AWS S3 — DEV Community
Cloud Security

Securely Accessing and Managing AWS S3

DEV Community

Practical patterns for access control, secure operations and responsible management of object storage.

The practical security problems around object storage are usually caused by ordinary shortcuts: credentials shared across scripts, permissions broader than the task requires, public access left open or logging added only after something goes wrong. I wrote this guide to make the safer path concrete through least-privilege access, encryption and automated monitoring. The idea I would underline today is that secure defaults reduce the number of decisions every engineer must remember. A platform can create narrowly scoped roles, block public access, enable encryption and produce audit records as part of its standard workflow. That is more reliable than expecting each application team to reproduce the same controls independently. Security also becomes easier to operate when identity and purpose are visible: teams should be able to determine which workload accessed an object and why. Good storage security is not a one-time configuration. It is a set of defaults, reviews and signals that continue to work as applications and teams change.

Read the original on DEV Community ↗
Monitoring and Analyzing Cloud Storage Costs — DEV Community
Cloud Economics

Monitoring and Analyzing Cloud Storage Costs

DEV Community

A guide to making storage cost visible enough to support engineering tradeoffs rather than retrospective surprises.

Cost becomes an engineering concern when it is visible close to the decision that creates it. Waiting for a monthly total makes it difficult to connect growth to a bucket, workload or change in access pattern. This article uses command-line and Python tools to expose storage usage and spending in a form that teams can inspect regularly. My broader interest is the relationship between cost, performance and reliability. The cheapest storage class may create unacceptable restore delay; the fastest option may be unnecessary for data that is rarely read. Useful monitoring therefore provides context rather than only a number. Teams should see how much data exists, how it is being accessed, which policies are changing and where unusual growth began. With that evidence, cost reviews become architecture conversations instead of emergency cleanup. I would also automate trend and anomaly checks early, because a small unexplained change is easier to investigate than a large bill after several months of accumulation.

Read the original on DEV Community ↗
Designing for Sustainability: The Rise of Green Software — DZone
Sustainable Engineering

Designing for Sustainability: The Rise of Green Software

DZone

How software architecture, infrastructure choices and operational discipline influence energy use and sustainability.

Sustainable software can sound abstract until it is connected to familiar engineering work. Unnecessary computation, repeated data movement, inefficient queries and overprovisioned infrastructure consume energy while also increasing cost and operational complexity. I wrote this article to frame sustainability as another consequence of architecture rather than a separate concern owned by a reporting team. The most useful improvements are often practical: reduce redundant storage, select efficient data structures, cache deliberately, schedule flexible work when capacity is available and measure resource use alongside performance. I would add that sustainability decisions need the same care as other optimizations. Moving computation or data can reduce one metric while increasing another, so teams need a system-level view and evidence from production workloads. The goal is not to attach a green label to every design. It is to make resource efficiency one of the tradeoffs engineers can see, discuss and improve over the life of a system.

Read the original on DZone ↗
Theme

Experimentation & Applied Mathematics

Using controlled evidence and mathematical models to understand complex behavior and improve decisions.

See related engineering interests →
Scaling and Monetizing Amazon Through Experimentation — DEV Community
Experimentation

Scaling and Monetizing Amazon Through Experimentation

DEV Community

A practitioner’s look at how disciplined experimentation shapes product decisions and durable customer experiences.

Experimentation matters because plausible ideas are not always useful ideas. At scale, even a small product change can affect different customers in different ways, and movement in one metric can hide a cost elsewhere. I wrote this article to make controlled testing more accessible, but the lesson I continue to return to is that an experiment begins with a decision—not with a dashboard. Teams should state what they expect to learn, which customer outcome matters and what evidence would cause them to stop or change direction. Good platforms make tests easier to run; good operating practice prevents teams from treating every statistically visible change as a durable improvement. Long-term effects, interaction between simultaneous tests and novelty can all complicate interpretation. Experimentation works best as decision infrastructure: a repeatable way to challenge assumptions, protect customers from broad untested changes and build shared confidence in what a product should do next.

Read the original on DEV Community ↗
Nonlinear Dynamics of Bimodality in Vehicular Traffic — Journal of Physics: Conference Series
Applied Mathematics & Traffic Dynamics

Nonlinear Dynamics of Bimodality in Vehicular Traffic

Journal of Physics: Conference Series

A mathematical study of why traffic-flow distributions can separate into two distinct modes, identifying the symmetry-breaking and bifurcation conditions behind transitions between bimodal and unimodal behavior.

This research explored a question that is easy to observe but harder to explain: why traffic flow can settle into two distinct patterns rather than one smooth distribution. The work uses nonlinear dynamics to connect bimodality with fixed points, symmetry breaking and bifurcation. What has stayed with me is the value of looking beyond averages. A single average speed or flow rate can hide the fact that a system is switching between qualitatively different states. That lesson carries into software systems as well. Aggregate latency, conversion or engagement can conceal multiple populations, operating conditions or failure modes. Mathematical models do not replace measurement of the real system, but they provide a disciplined way to ask which mechanisms could produce the behavior we see. I remain interested in that bridge between theory and engineering: identify the structure of the problem, test whether the model explains observed transitions and use the mismatch to refine both the assumptions and the measurement.

Read the original on Journal of Physics: Conference Series ↗
Dynamics of Bimodality in Vehicular Traffic Flows — arXiv
Nonlinear Dynamics

Dynamics of Bimodality in Vehicular Traffic Flows

arXiv

The open-access precursor to the journal paper develops a traffic-flow model that connects bimodal behavior with fixed points, homoclinic trajectories, symmetry breaking and bifurcation.

The arXiv paper captures an earlier stage of the traffic-flow research, when the central task was to build a model capable of producing the bimodal behavior observed in the data. We examined how fixed points and trajectories change as system parameters move, and how symmetry breaking can produce a transition between different flow regimes. Publishing the precursor openly was useful because it exposed the reasoning, not just the final result. Readers could see the model evolve and compare its structure with related nonlinear systems. Looking back, I value that process as much as the specific traffic application. Complex engineering systems also show abrupt transitions: a queue that appears stable until load crosses a boundary, or a feedback loop that changes behavior after a delay. The vocabulary of stability, bifurcation and competing modes provides another way to reason about those shifts. It encourages engineers to ask not only what the system is doing now, but what small change could move it into a different operating state.

Read the original on arXiv ↗

Continue the conversation

I share new work on engineering systems, measurement, privacy and experimentation as it is published.

Connect on LinkedIn ↗