Engineering case studies

Correctness under real constraints.

Production work across fintech, retail, and security. Each case distinguishes my contribution from the broader team outcome.

PayPal, Inc. · 2024–present

Billing and Usage Platform

Connecting merchant APIs, usage events, and financial state in a greenfield billing platform.

My role: Foundational contributor; co-designed platform and API capabilities

The engineering problem

Usage billing connects two very different workloads: merchants need responsive APIs, while usage arrives asynchronously and may be late or duplicated. A reliable platform has to preserve the relationship between a usage event and its financial effect through retries, aggregation, and invoicing.

The approach

I developed Java and Spring services across metering, aggregation, rating, invoicing, refunds, and subscription calculations. Working with the team, I co-designed synchronous merchant APIs and Kafka/MSK processing paths, with ClickHouse for analytical ingestion and PostgreSQL and Redis for transactional and caching workloads.

Design decisions

Make event behavior explicit: Transaction identifiers, deduplication, late-event handling, and replay semantics were part of the processing contract.
Isolate merchant workloads: Cell-based, multi-tenant design and tier-aware quotas provided controls for overload and independent scale.
Design the operating model: Recovery runbooks, dependency-aware health checks, telemetry, and merchant documentation accompanied the services.

Outcome and scope

The team delivered the platform to production in approximately six months. My contribution spanned service implementation, API design, performance engineering, operational readiness, and integration guidance.

Nordstrom, Inc. · 2020–2024

Fulfillment Optimization

Moving fulfillment decisions beyond distance-only routing, with controlled experiments and operational fallbacks.

My role: Design lead and platform owner, partnering with Data Science

The engineering problem

The nearest fulfillment location is not always the best choice. Labor, carrier rates, surcharges, and delivery commitments all influence the cost of a decision. Turning a solver into a production service meant making those inputs timely, consistent, and explainable.

The approach

I hosted Gurobi and built the adapter between operational requests and solver inputs and outputs. The service enriched requests with eligibility, labor and carrier costs, and Finance-defined conversion of delivery speed to cost. Precomputed geographic matrices and warm starts helped keep optimization within the API latency budget.

Design decisions

Compare equivalent decisions: Historical purchase-order replay and Optimizely traffic splits compared distance-only, cost-only, and speed-and-cost models.
Keep rollout reversible: Routing controls, fallbacks, retries, and observability let stakeholders evaluate a model before extending its traffic.
Make inputs a shared contract: Engineering worked with Finance, Supply Chain, ETA, Data Science, and warehouse stakeholders on assumptions and release decisions.

Outcome and scope

Backtests and production experiments identified approximately 20–25% cost-reduction opportunities relative to the distance-only baseline, primarily through fewer express upgrades and late penalties. The v5 model ramped from 5% to 100% of targeted traffic over approximately three months.

Nordstrom, Inc. · 2020–2024

Rules-Based Store Allocation

Replacing slow, manual allocation workflows with an explainable engine that planners could control.

My role: Led feasibility, algorithm design, data contracts, and implementation

The engineering problem

Store allocation must respect pack sizes, demand, size distributions, and store priorities. Slow purchase-order processing compounded into backlogs, while planners still needed understandable controls over how inventory was placed.

The approach

I led the design and Java/Spring Boot/Kafka implementation of an in-house allocation engine. The algorithm allocated for coverage first, then distributed the remainder by need. It combined store rotation and pack-size integrity with Data Science size curves and planner-controlled coefficients and store clusters.

Design decisions

Preserve business constraints: Pack-size integrity and adaptive quality gates made the allocation valid as well as fast.
Make runs reproducible: Versioned runs and PostgreSQL audit records supported comparisons and investigation.
Validate with the people using it: Historical comparisons, shadow validation, and phased rollout connected technical results with planner expectations.

Outcome and scope

Processing dropped from approximately 9–12 minutes per purchase-order line to under 30 seconds per line. Peak backlogs of two to three days were replaced by processing close to purchase-order creation.

Nordstrom, Inc. · 2020–2024

Marketplace Inventory Platform

Building a consistent inventory model across store, warehouse, and vendor availability.

My role: Founding engineer on marketplace inventory infrastructure

The engineering problem

Inventory is more than a count. Transfers, returns, vendor feeds, and warehouse changes all affect what can be sold. A marketplace platform must preserve the meaning and order of those changes across multiple projections and downstream services.

The approach

I designed core components using Aurora/PostgreSQL, Debezium, Kafka, and streaming projections. An ordered inventory ledger and canonical state model connected inventory lifecycle changes to explicit sellable and non-sellable semantics and availability read services.

Design decisions

Model operations, not isolated messages: Operation-level ordering kept related lifecycle changes coherent.
Separate history from projections: Projection contracts and deterministic rebuild mechanisms made derived state recoverable.
Treat vendor ingestion as part of correctness: Vendor-feed ingestion, feasibility APIs, and idempotency linked outside availability to the shared inventory model.

Outcome and scope

The platform spanned more than 377 facilities and was designed for approximately 100,000 events per second. Those figures describe platform scope and design capacity, not a claim that every workload sustained that rate.

Nordstrom, Inc. · 2020–2024

Kafka Partitioning and Recovery

Separating high-volume traffic from critical operations and making failed publishes recoverable.

My role: Designed partitioning changes and bounded recovery tooling

The engineering problem

Inventory-adjustment traffic represented approximately 80% of the workload and delayed other consumers. Related operation events on different partitions also created database write contention. Broker maintenance introduced a separate problem: identifying and safely republishing failed records.

The approach

I redesigned partitioning to co-locate lifecycle events for the same operation and isolate inventory-adjustment traffic in dedicated partition bands. Topic, key, and schema contracts were preserved so downstream consumers did not require rewrites. For recovery, I designed an ephemeral Kubernetes worker with explicitly bounded replay.

Design decisions

Protect operation affinity: Co-location aligned the event stream with the database mutation boundary.
Bound every replay: Replay could be scoped by topic, partition, offset, or time window, with read-committed consumption and event-type filtering.
Make recovery terminate: Conditional-write idempotency and automatic worker termination replaced open-ended manual republishing.

Outcome and scope

Post-isolation measurements showed approximately 100% higher throughput for critical Transfer, RTV, Notification, and Supply Chain streams. The recovery worker replaced manual record identification and republishing with bounded, observable replay.

Nordstrom, Inc. · 2020–2024

Oracle CDC and Cost Accounting

Preserving source transaction context while streaming retail changes into financial projections.

My role: Designed transaction reconstruction; led the cost-accounting pipeline

The engineering problem

Record-level CDC provides speed, but financial consumers also need transaction context. A single inventory movement can produce many cost events, so a fast pipeline is not enough: accounting must be able to trace and reconcile the result.

The approach

I designed Splitter and Stitcher processing around Oracle GoldenGate CDC, using commit sequence numbers and transaction identifiers for reconstruction. Redis-backed offset and state persistence preserved context across pod recovery and rolling deployments. A Java/Spring/Kafka pipeline connected retail sources to downstream cost-accounting systems.

Design decisions

Keep transaction provenance: Downstream events retained the context required to trace a financial result to its source.
Recover processing state: Persisted offsets and reconstruction state supported restarts without discarding transaction context.
Validate through reconciliation: Historical replay, backfill, schema governance, load testing, and a year-long reconciliation pilot preceded production cutover.

Outcome and scope

The pipeline enabled near-real-time item-level weighted-average cost, item-location stock-on-hand projections, and end-of-week accounting snapshots. It was designed for approximately 100,000 transactions per second; an inventory movement could generate more than 100 cost events.

Securonix, Inc. · 2016–2020

SolrCloud Search Architecture

Scaling security investigation across high-volume indexing and hot, warm, and cold data.

My role: Software engineer across ingestion, query processing, and search infrastructure

The engineering problem

Security analysts need useful search over rapidly arriving events and older history. Ingestion, enrichment, indexing, and query execution compete for resources, while multi-tenant workloads need predictable routing and recovery.

The approach

I developed Kafka- and Redis-backed ingestion and enrichment pipelines and extended Spotter’s domain-specific query language. I optimized Solr query paths and document routing, worked on implicit sharding, and separately designed indexing across multiple SolrCloud clusters.

Design decisions

Route work deliberately: Document and tenant-aware routing controlled how indexing and query work reached search infrastructure.
Connect storage tiers: Aggregation stitching preserved statistics and facets across Solr and HDFS/Impala.
Preserve the investigation workflow: Amazon S3 and Athena query paths supported SaaS cold-history access without changing the analyst’s core workflow.

Outcome and scope

Solr performance improved approximately twofold through tuning, routing, and implicit sharding. Separately, the multi-cluster indexing design supported rates up to approximately 500,000 events per second. These are distinct performance results.

More on recovery and reliability

My public writing and talks explore the patterns behind these systems using generalized examples.

Technical publications Conference talks Discuss engineering work