← Back to Blog

Concurrency: The Story We Tell vs. the System We Run

concurrencydata-engineeringhealthcare-analytics

Concurrency: The Story We Tell vs. the System We Run

Most people say concurrency and mean parallelism: more workers, more threads, more partitions, more speed.

Production hears “more” and replies: shared resources, contention, queues, retries, and somebody waiting.

Concurrency in practice is not “how many things can run.” It’s which things are allowed to make progress when everything is busy.

The perception gap

What we imagine:

What we deploy:

A realistic data pipeline view

flowchart LR
  P[Producers<br/>events • batches • backfills] --> Q[Bounded Queue]
  Q --> O[Orchestrator / Scheduler]
  O --> W1[Worker]
  O --> W2[Worker]
  O --> W3[Worker]

  W1 --> D[(Warehouse / DB)]
  W2 --> D
  W3 --> D

  W1 --> M[(Metastore / Catalog)]
  W2 --> M
  W3 --> M

  W1 --> X[External APIs]
  W2 --> X
  W3 --> X

  D -->|locks/slots| B[Backpressure<br/>caps • jitter • fail fast]
  M -->|commit contention| B
  X -->|429/quota| B

  B --> Q

If you’re “scaling” without bounded queues + per-sink concurrency caps + sane retry policy, you’re usually just speeding up your failure mode.

What changes in healthcare analytics

Same concurrency mechanics, higher stakes:

So the goal isn’t max throughput. It’s predictable truth.

The only definition that consistently helps

Concurrency is shared progress under contention.

Ask these instead of “how many workers”: