Daniel Sosinskiy
← Back to Engineering Stories Production systems / Conbo

Aggregating signals from five APIs

A warnings and statistics service that brought five upstream responses into one backend flow.

At a glance

My role · I designed and shipped the per-deployment warnings and statistics service within a larger team system. I did not own all upstream APIs or the entire platform.

Context · Professional work, with company details generalized.

Context

The product presents operational information to teams working at ports and warehouses. The system uses camera, detection, and RFID data; this account generalizes its boundaries and omits customer and infrastructure details.

The Problem

Warnings and statistics depended on information held by multiple services. The feature needed to gather those inputs, evaluate configurable rules, maintain a current view, and expose it through a stable API.

My role

I designed and shipped the per-deployment warnings and statistics service within a larger team system. I did not own all upstream APIs or the entire platform.

Technical Approach

  • Aggregated data from five upstream APIs.
  • Evaluated configurable warning rules and maintained current state.
  • Exposed warnings and statistics through HTTP endpoints. The frontend delivery path used HTTP polling.

Generalized process

  1. Five upstream APIs
  2. Aggregate inputs
  3. Evaluate rules
  4. Maintain state
  5. HTTP endpoints
  6. Operator UI

Decisions and Tradeoffs

Put aggregation behind a service boundary

Clients could read a rule-evaluated view without coordinating five upstream responses themselves.

Use HTTP for the consumer path

The operator interface polled HTTP endpoints. This story does not claim a WebSocket delivery path.

Alternative to revisit

If update needs or client volume change, a pushed update channel could be evaluated. It is an alternative to explore, not a shipped result claimed here.

Outcome

The shipped service exposes configurable warnings and current statistics through HTTP endpoints. No latency, uptime, adoption, or business-impact metric is claimed.

Reflection

A useful next step would be to document rule behavior and failure handling more explicitly as usage changes.

Technologies

  • TypeScript
  • NestJS
  • REST APIs

Links

No public repository or live demo is available for this professional work.

© 2026 Daniel SosinskiyIsrael