Backend & REST API Development for Hardware Products
Cloud backends purpose-built for IoT, device management, and hardware data pipelines — ingestion APIs that scale to millions of devices, device twin management, time-series data, and mobile app APIs that turn hardware telemetry into actionable product features.
What We Build on This Platform
Device Ingestion APIs
High-throughput REST and MQTT ingestion endpoints for sensor telemetry, device state, and event streams from IoT devices at scale. Ingestion paths are designed as write-optimized pipelines separate from query paths, with message queue buffering to isolate device connection volume from database write throughput.
Device Twin & State Management
Server-side device twin with desired and reported state documents, bidirectional sync, command queuing, and optimistic locking for multi-client concurrent update scenarios. The twin model provides a consistent API surface for device configuration regardless of whether the device is currently online or offline.
Time-Series Data & Dashboards
TimescaleDB or InfluxDB time-series schema design, hypertable partitioning, continuous aggregates for dashboard query performance, and REST API endpoints that serve pre-aggregated data to avoid full-table-scan queries in the critical dashboard rendering path.
WebSocket & Real-Time Push
WebSocket server for live device data streaming to web and mobile clients, MQTT-to-WebSocket bridge for real-time telemetry dashboards, and server-sent events (SSE) for read-only push streams where WebSocket bidirectionality is not required and connection load balancing is simpler.
Authentication & Authorization
JWT authentication with refresh token rotation, OAuth2 device authorization flow for headless device credential issuance, API key management with per-key rate limits and scope restrictions, and role-based access control with organization-scoped data isolation for multi-tenant IoT SaaS platforms.
OTA Update Infrastructure
Device firmware OTA server with semantic version management, staged rollout percentage control, per-device and per-group targeting, download progress tracking via device-reported status, and update campaign management with automatic rollback on elevated error rates reported by devices post-update.
Mobile App API
Mobile-optimized REST API with GraphQL for complex relational data queries, cursor-based pagination for infinite scroll telemetry history, field selection to minimize response payload on constrained mobile connections, and offline-first sync patterns for companion mobile apps that must function without continuous connectivity.
Infrastructure as Code & CI/CD
Terraform infrastructure definitions for reproducible staging and production environments, Docker multi-stage container builds for minimal image size, Kubernetes deployment manifests with horizontal pod autoscaler configuration, and GitHub Actions pipelines for automated test, build, and deploy on every pull request.
How Ankh Uses This Platform
Device Data Model & API Contract
Device identity model is defined first: device ID (UUID v4 generated at provisioning), hardware serial number, firmware version, last-seen timestamp, connection state, and organization ownership. Telemetry schema is designed for the sensor payload — field names, units, precision, and timestamp format are specified in the data model before any code is written. OpenAPI 3.1 specification is written before implementation begins and shared with firmware and mobile teams for parallel development; this enables firmware engineers to test against a mock server and mobile engineers to generate client SDK code without waiting for backend completion. URL path versioning (/v1/, /v2/) is used rather than header versioning because it produces simpler curl debugging and more predictable CDN cache key behavior for device clients.
Ingestion Architecture
MQTT broker selection — AWS IoT Core for GMS-compatible devices needing managed infrastructure, HiveMQ for on-premises or private cloud deployments, self-hosted Mosquitto for development — is made based on connection volume, geographic distribution, and operations burden tolerance. MQTT is chosen for devices that maintain persistent connections and require bidirectional command delivery; REST is chosen for batch-upload devices that wake, POST a payload, and sleep. A message queue (SQS for AWS deployments, RabbitMQ or Kafka for on-premises) sits between ingestion and processing to absorb the reboot storm that follows a firmware update broadcast: 10,000 devices reconnecting within a 5-minute window generates a write spike that would saturate a directly-connected database writer. TimescaleDB hypertable schema uses device_id and time as the partition key, with chunk interval set for the expected data retention and query window.
Authentication & Multi-Tenancy
JWT token structure is designed with standard claims (sub, iat, exp) and custom claims for organization_id, device_id (for device tokens), and role. Device credential provisioning is defined for the manufacturing workflow: a per-device API key or X.509 certificate is generated at the provisioning station, verified against the device serial number, and written to NVS or secure storage on the device before it leaves the factory. Multi-tenant data isolation is implemented at the database query level with organization_id on every tenant-scoped table, enforced via PostgreSQL Row Level Security policies that activate based on the current_setting('app.current_organization_id') session variable set by the connection middleware — this ensures that even queries with programming errors cannot leak cross-tenant data.
API Implementation & Testing
OpenAPI-first implementation uses request validation middleware (Zod schema derived from the OpenAPI spec, or express-openapi-validator for Node.js) to reject malformed device payloads at the API boundary before they reach business logic. Integration tests run against a local PostgreSQL + Redis + Mosquitto instance via Docker Compose, covering the full request lifecycle including authentication, database writes, and queue message production. Load tests with k6 simulate the expected peak device connection count — burst ingestion scenarios (firmware OTA completion, daily sync window) are tested separately from steady-state scenarios. Rate limiting is applied per device token and per organization API key, with different limit profiles for device ingestion (higher burst tolerance) and mobile app endpoints (lower burst, higher sustained).
Deployment & Monitoring
Docker multi-stage build produces a minimal production image — build stage compiles TypeScript or runs Gradle, final stage copies only the compiled output and production node_modules into a distroless base. Kubernetes deployment with HPA (Horizontal Pod Autoscaler) scales on CPU and custom MQTT connection count metrics. Terraform infrastructure definitions are maintained for staging and production, with workspace-based configuration for environment-specific variables. CloudWatch or Datadog collects four key signals: ingestion request rate (devices/second), ingestion error rate, database connection pool utilization, and message queue backlog depth. Alerts fire at defined thresholds before degradation reaches the device layer: queue backlog growth is detected before device timeouts occur, not after.
Deep Technical Capability
Time-Series Schema Design for High-Cardinality IoT Telemetry
The naive IoT telemetry schema — a wide table with device_id as a VARCHAR column and one column per sensor reading — produces catastrophic query performance at scale. TimescaleDB's hypertable model partitions data by time chunk (1 day to 1 week depending on ingest rate), enabling chunk exclusion to reduce I/O for time-bounded queries to only relevant chunks. The cardinality problem appears when device_id is treated as a tag dimension: with 50,000 devices emitting at 10-second intervals, a naive GROUP BY device_id query over 24 hours scans 432 million rows. Continuous aggregates — pre-computed materializations of common aggregation windows (1 minute, 1 hour, 1 day) — eliminate this scan cost, reducing a 5-second dashboard query to under 100 milliseconds. The tradeoff is write amplification: each raw insert triggers incremental materialization work across active aggregate policies. Chunk compression, enabled after the active query retention window, reduces on-disk storage by 90–95% for numerical sensor data via TimescaleDB's delta-delta and gorilla algorithms. Schema design for write throughput (batched inserts, minimal raw-table indexes) conflicts with schema design for query latency (covering indexes, partial indexes per device group); the resolution is separate ingestion and query schemas bridged by the continuous aggregate layer.
MQTT Connection Scaling and Backpressure
MQTT QoS 0 (at-most-once) is appropriate for high-frequency sensor telemetry where occasional loss is acceptable; QoS 1 (at-least-once) is required for device commands, OTA notifications, and any message where delivery must be confirmed. QoS 2 (exactly-once) carries a four-way handshake overhead that makes it impractical at telemetry scale — the latency and broker memory cost of the per-message state machine eliminates its value where network retransmission already provides adequate reliability. Session persistence — storing undelivered QoS 1+ messages for reconnecting clients — is the primary scaling constraint for large deployments: at 100,000 concurrent persistent sessions, broker memory for session state grows to multi-gigabyte scale. AWS IoT Core manages this transparently; self-hosted HiveMQ or Mosquitto require explicit session expiry interval configuration to bound memory growth. Backpressure propagation is the most insidious failure mode: a database write bottleneck causes the processing consumer to fall behind on the message queue, queue depth grows, broker memory fills with undelivered messages, and MQTT publish acknowledgements slow — triggering device-side publish timeouts and reconnect storms that amplify the original bottleneck by an order of magnitude.
Multi-Tenant Data Isolation in PostgreSQL for IoT SaaS Platforms
Row Level Security (RLS) in PostgreSQL enables per-row access control enforced at the database engine level, below the application code. For IoT SaaS platforms, the policy pattern is: every tenant-scoped table carries an organization_id column, an RLS policy filters SELECT/INSERT/UPDATE/DELETE to rows where organization_id equals the session variable set by the connection middleware, and the policy is marked USING rather than WITH CHECK so it applies to writes as well as reads. The performance tradeoff is real: RLS policy evaluation adds approximately 5–15% overhead to simple queries on indexed columns, rising to 30%+ for queries that require a sequential scan with per-row policy check. The mitigation is ensuring every query against RLS-enabled tables hits a partial index that includes the organization_id predicate. PgBouncer connection pooling in transaction mode is compatible with session-variable-based RLS, but the middleware must SET LOCAL app.current_organization_id within the transaction rather than SET, as SET persists across transaction boundaries in a pooled connection and can leak the organization context to the next query. For regulated industries — healthcare, financial, critical infrastructure — RLS-enforced isolation provides a demonstrable technical control for the cross-tenant data leakage risk that compliance auditors require evidence of.
Products Built on This Platform
IoT Devices
Device ingestion API, device twin management, and OTA update infrastructure for connected hardware fleets.
View ProductFleet Telematics
High-frequency GPS and CAN telemetry ingestion, time-series storage, and real-time tracking API.
View ProductMedical Devices
HIPAA-compliant IoT backend with multi-tenant isolation, audit logging, and device data provenance.
View ProductSmart Home Automation
Device state management, WebSocket real-time push, and mobile app API for connected home hardware.
View ProductCold Chain Monitoring
Temperature telemetry ingestion with threshold alerting, excursion reporting, and regulatory audit trail API.
View ProductStructural Monitoring
Long-duration sensor data ingestion with continuous aggregate dashboards and anomaly alerting backend.
View ProductBackend systems designed for the device data model, not adapted from web app patterns
A backend built for a SaaS web application handles user sessions, form submissions, and relational queries. A backend built for 50,000 IoT devices handles disconnection and reconnection state, burst ingestion from synchronized firmware wake windows, device identity that exists before any user account is created, and data that must be queryable by time range across devices simultaneously. Ankh designs these systems from the device data model outward — the device identity schema, the telemetry time-series structure, and the command delivery model are defined before the first API endpoint is written. This produces backends that handle real IoT failure modes instead of discovering them in production.
Ingestion APIs that survive the device reboot storm after a firmware update
The most predictable high-load event in any IoT deployment is not organic growth — it is the firmware update broadcast. When 10,000 devices receive an OTA notification simultaneously, apply it, reboot, and reconnect within a 5-minute window, the ingestion spike is 20–50x the steady-state connection rate. Ankh designs ingestion pipelines with explicit burst tolerance: message queue buffering between the MQTT or REST ingestion layer and the database write layer, connection pool sizing for peak reconnection rate, and database write batching that maintains throughput under burst load. These design decisions are validated with load tests simulating the reboot storm before any production deployment, not after.
Multi-tenant isolation that satisfies the compliance audit, not just the sprint demo
IoT platforms serving healthcare, industrial, or critical infrastructure customers face compliance audits that require documented evidence of cross-tenant data isolation. An application-level WHERE organization_id = ? clause satisfies the sprint demo; PostgreSQL Row Level Security with demonstrable enforcement at the database engine level satisfies the SOC 2 Type II auditor and the HIPAA technical safeguard review. Ankh implements RLS from the initial schema design, documents the policy enforcement model in the technical architecture, and prepares the query execution plan evidence that compliance reviewers require. We have supported customers through audit processes where the backend data isolation model was a primary review focus.