S14H — Index
S14H FIELD ARCHIVEEd. 2026.09
An engraved frontispiece: a ruined aqueduct on the left, a citadel of spires on the right, a river valley between them, a compass star and moons in the sky, and an orange sun, like a beacon, on the horizon.

Sina Afsharmanesh S14H

Pl. I — FrontispieceSurvey of the valley: the old works, the long river, the citadel beyond.

I build systems that move data from machines to decisions.

Senior software engineer at Golrang System. I work on the whole road a signal travels, from where it is born to where it is finally read: data infrastructure, distributed systems, industrial telemetry, and the applications people read it through.

Current focus: Data infrastructure

Role
Senior software engineer
Organization
Golrang SystemThe technology organization supporting Golrang Industry Group.
Current focus
Data infrastructure
Disciplines
Data infrastructure / Distributed systems / Industrial IoT / Full-stack applications
Correspondence
s14h@proton.me

02 / Work

Case files

Every structure here was raised against a constraint: analytics too heavy for a browser, links that drop and requeue, identities already in place, a compute engine that keeps changing. Read them in order.

Register

001Enterprise Data Platform
Domain
Enterprise analytics
Environment
Internal, enterprise
Stack
C# / .NET / Next.js and 3 more
002Industrial IoT & OPC UA Platform
Domain
Industrial IoT
Environment
Industrial sites, edge to backend
Stack
Go / OPC UA and 3 more
003On-Prem Data Platform
Domain
Data platform
Environment
Enterprise, on-premises
Stack
PostgreSQL / Supabase and 3 more
004Lakehouse on Object Storage
Domain
Data architecture
Environment
Containerized development
Stack
Apache Spark / Apache Iceberg and 2 more

Case / 001Data platform

Enterprise Data Platform

Domain
Enterprise analytics
Environment
Internal, enterprise
Scope
Services, frontends, export pipeline

An internal platform for data access and analytics, carrying legacy enterprise BI into a typed web application.

Problem

Enterprise analytics lived in legacy BI engines, SQL Server and Analysis Services, where the result sets people needed were too large for a browser.

Approach

C#/.NET services and Next.js frontends query SQL Server and Analysis Services through typed APIs. Large result sets stream through worker-based export rather than the browser.

Technical details

  1. 1Typed APIs over SQL Server and Analysis Services
  2. 2Worker-based streaming export
  3. 3Exports to CSV, XLSX, Parquet and PDF

Stack

C# / .NET / Next.js / SQL Server / SSAS / Streaming

Discuss this case: Enterprise Data Platform
Fig. 1 — Typed services take the query; large results bypass the browser and stream to export workers.
  1. SQL Server → .NET services (query)
  2. .NET services → Next.js (typed)
  3. .NET services → Export workers (large results)
  4. Export workers → CSV · XLSX (export)

Case / 002Industrial telemetry

Industrial IoT & OPC UA Platform

Telemetry infrastructure for industrial environments, built for links that drop and requeue.

Domain
Industrial IoT
Environment
Industrial sites, edge to backend
Scope
Edge clients, messaging, processing, storage
Pl. II — Fig. 2
Fig. 2 — From machine to consumer, every hop assumes the link beneath it can fail.
  1. Machines → OPC UA client (X.509)
  2. OPC UA client → RabbitMQ (reconnect)
  3. RabbitMQ → Processing
  4. Processing → MongoDB
  5. MongoDB → Consumers

Problem

Process data has to leave the edge and reach systems that can query it, across links that drop, reconnect and requeue. It has to keep working when the network does not.

Approach

OPC UA clients feed RabbitMQ, processing services, MongoDB and the consumers downstream of them, with reconnection, buffering and requeue built into the path, and X.509 certificate security on the wire.

Technical details

  1. 1OPC UA clients at the edge
  2. 2Reconnection, buffering and requeue across unreliable links
  3. 3X.509 certificate security on the wire

Stack

Go / OPC UA / RabbitMQ / Redis / MongoDB

Discuss this case: Industrial IoT & OPC UA Platform

Record

Domain
Data platform
Environment
Enterprise, on-premises
Scope
Platform assembly, identity, storage, dashboards

Case / 003On-premises

On-Prem Data Platform

A data platform assembled from open-source pieces for an enterprise on-premises environment.

Problem

A data platform had to run inside an enterprise on-premises environment and accept the identities already there.

Approach

PostgreSQL and Supabase behind Keycloak and Active Directory SSO, MinIO for S3-compatible object storage, Kong at the edge, row-level security, and Next.js dashboards and admin tooling.

Technical details

  1. 1Keycloak and Active Directory single sign-on
  2. 2Row-level security in PostgreSQL
  3. 3MinIO for S3-compatible object storage
  4. 4Kong at the edge

Stack

PostgreSQL / Supabase / Keycloak / MinIO / Next.js

Discuss this case: On-Prem Data Platform
Fig. 3 — Open-source parts inside one identity boundary, with row-level security down to the data.
  1. Active Directory → Keycloak (federate)
  2. Keycloak → Kong (token)
  3. Kong → Supabase
  4. Kong → MinIO
  5. Supabase → Next.js

Case / 004Architecture & prototype

Lakehouse on Object Storage

Domain
Data architecture
Environment
Containerized development
Scope
Architecture and prototype
Maturity
Early-stage by design, not a production deployment

MaturityEarly-stage by design, not a production deployment

Architecture and prototype work on a lakehouse built from Apache Spark and Apache Iceberg.

Problem

Table formats, catalogs and object storage: the parts that still matter after the compute engine changes.

Approach

Apache Spark and Apache Iceberg with an Iceberg REST catalog over S3-compatible storage, Spark Connect for remote access, and containerized development infrastructure.

Technical details

  1. 1Iceberg REST catalog over S3-compatible storage
  2. 2Spark Connect for remote access
  3. 3Containerized development infrastructure

Stack

Apache Spark / Apache Iceberg / REST catalog / MinIO / S3

Discuss this case: Lakehouse on Object Storage
Fig. 4 — Compute is replaceable; table format, catalog and storage are the durable layer.
  1. Client → Apache Spark (remote)
  2. Apache Spark → Iceberg (tables)
  3. Iceberg → MinIO / S3 (metadata)
  4. Apache Spark → MinIO / S3 (data)

03 / About

Every interesting problem lives on a border.

Hardware and software. Edge and backend. Old analytics and new platforms. The org chart draws those lines; the problem ignores them.
Fig. III.aThe moon that keeps the survey's hours.

§ 3.1

Dossier

I work at Golrang System, on data infrastructure. Earlier work reached further out: embedded and industrial software, OPC UA telemetry, and the applications built around those systems.

I care about software that stays understandable under load and failure, and about simple, explicit architecture over abstraction for its own sake. I started programming at 17, with C++ and a robotics club.

  1. Rule 01

    Simple, explicit architecture over abstraction

  2. Rule 02

    Performance and reliability under real load

  3. Rule 03

    Observability and secure boundaries by default

File S14H / Profile

Name
Sina Afsharmanesh
Handle
S14H
Role
Senior software engineer
Organization
Golrang System
Current focus
Data infrastructure
Disciplines
Data infrastructure / Distributed systems / Industrial IoT / Full-stack
Languages
Go, C#, Rust, TypeScript, SQL
First program
At 17. C++, robotics club
Boundary mapFour boundaries, each a pair: Hardware to Software; Edge to Backend; Legacy analytics to Modern platforms; Data to Application. A dashed vertical line marks the boundary between the two sides; signal paths cross it in both directions and an orbit crosshair sits on the line.HardwareSoftwareEdgeBackendLegacy analyticsModern platformsDataApplication

Signal path — crosses the boundaryBoundary — dashed line

Fig. 3.1 — Boundary map

§ 3.2

Capabilities

§ 3.3

Chronology

I work at Golrang System, the technology organization supporting Golrang Industry Group. The systems have changed more than the employer has.

Dates omitted: this record is ordered from current work outward.

  1. E.1

    Current

    Data Infrastructure

    My current team works on data infrastructure: the storage, pipelines and access layers that make data dependable for everything built on them.

    Stack: PostgreSQL / Spark

  2. E.2

    Industrial IoT & Automation

    Industrial software and telemetry. OPC UA clients on the edge, messaging and storage behind them, and the integrations that carry process data into other systems. It has to keep working when the network does not.

    Stack: Go / OPC UA / RabbitMQ

  3. E.3

    Senior Full-Stack Development

    The web applications, dashboards and admin tooling over the data and industrial systems, built to stay fast with large result sets and real users in them.

    Stack: TypeScript / Next.js / C#

  4. E.4

    Data Engineering & Backend

    Data engineering and backend services, including the enterprise data platform that exposes SQL Server and Analysis Services through typed APIs and streamed exports.

    Stack: C# / .NET / SQL

04 / Notes

Open excavations

Industrial telemetry, enterprise data, and the architecture beneath both. Subjects still in the ground, not publications: nothing below has been published yet.

Internal catalogue · subjects in progress

Doc N-01Open topic

Industrial

OPC UA telemetry

Getting process data off the edge and into systems that can query it, across links that drop, reconnect and requeue.

Go / OPC UA / RabbitMQ

Doc N-02Open topic

Data

Enterprise data access

Legacy BI engines behind typed APIs, with large query results streamed and exported by workers rather than the browser.

C# / .NET / SQL Server / SSAS

Doc N-03Open topic

Architecture

Lakehouse foundations

Table formats, catalogs and object storage: the parts that still matter after the compute engine changes.

Spark / Iceberg / MinIO / S3

Filed: 3 topics · Published: 0

05 / Archive

Drawer of fragments

Small things recovered from the field. Each is true of everything above.
Fig. V.aCompass star. Every bearing is taken from it.
  • FRG-01First trace

    Started programming at 17, with C++ and a robotics club.

  • FRG-02Field condition

    It has to keep working when the network does not.

  • FRG-03Working rule

    Simple, explicit architecture over abstraction.

  • FRG-04Load condition

    Performance and reliability under real load.

  • FRG-05Boundary rule

    Observability and secure boundaries by default.

  • FRG-06Durable layer

    Table formats, catalogs and object storage still matter after the compute engine changes.

  • FRG-07Org chart

    The org chart draws the lines; the problem ignores them.

Type specimen: the handle S14H, knocked out of a halftone screen in the display face.

06 / Contact

Send word across the valley.

Distributed systems, data platforms, industrial telemetry, or the applications built around them. If one of those is your problem, write.
Fig. VI.aThe orange sun at the edge of the map, lit like a beacon.

Correspondence

s14h@proton.me
Channel
Email
Address
s14h@proton.me
Code
github.com/Sina-Afsharmanesh