Blog

IoT projects are often perceived as pilot deployments with a limited number of devices. In real-world environments, the scale is very different — thousands or tens of thousands of sensors, controllers, and connected assets transmitting data continuously in a 24/7 mode.

At OneDev, we work with telemetry systems where the main objective is not to demonstrate connectivity, but to ensure reliable data collection and processing under unstable networks, high load, and long-term operation.

Below is a practical view of how IoT platforms operate in production environments.

What an IoT Platform Looks Like in Practice

An IoT platform is an infrastructure system that manages the full lifecycle of device data.

Its core responsibilities include:

• • device connectivity and lifecycle management
• • real-time telemetry ingestion
• • storage of large data volumes
• • event and anomaly detection
• • integration with external systems

In production environments, scalability, fault tolerance, and operational visibility become the key priorities.

Telemetry Collection, Storage, and Analysis

Data Ingestion

Devices may transmit data at different intervals — from seconds to several times per day. The platform must:

• • receive messages without data loss
• • handle traffic spikes
• • buffer data during connectivity issues
• • support asynchronous processing

Data Storage

Telemetry is primarily time-series data. Efficient handling requires:

• • scalable storage systems
• • separation of operational and historical data
• • data retention and aggregation policies
• • indexing for fast queries

Analytics and Event Processing

• • detecting deviations from normal behavior
• • generating events and incidents
• • calculating aggregated metrics
• • predicting load patterns and potential failures

Protocols and Device Connectivity Approaches

Different communication protocols are used depending on device capabilities and network conditions:

• • MQTT — lightweight and reliable messaging
• • HTTP/HTTPS — for devices with stable connectivity
• • CoAP and other lightweight protocols
• • industrial protocols via gateways

A typical architecture includes:

• • field devices
• • edge gateways for aggregation and filtering
• • message brokers
• • processing and storage layers

The use of brokers and queues ensures system stability under intermittent connectivity.

Scaling Challenges in IoT Systems

Unstable Networks

Devices may disconnect, send delayed data, or retransmit messages. The platform must handle these scenarios correctly.

Load Spikes

Mass reconnections or synchronized reporting can cause sudden traffic peaks, requiring horizontal scaling and load balancing.

Device Management

• • registration and identity management
• • configuration updates
• • health monitoring
• • remote firmware updates

Data Volume Growth

Even small messages become large datasets when multiplied across thousands of devices, requiring optimized storage and processing strategies.

Operational Dashboards and Alerting

A production IoT platform must include operational visibility tools.

• • real-time device status monitoring
• • online/offline tracking
• • data volume and traffic monitoring
• • analytics by region, group, or device type

Alerting mechanisms notify operators when:

• • devices lose connectivity
• • parameters exceed thresholds
• • anomalous behavior is detected
• • data processing failures occur

In real environments, these dashboards are used daily and form the foundation of system operations.

Our Approach to IoT Projects

At OneDev, IoT solutions are treated as long-term infrastructure rather than pilot initiatives.

• • architecture designed for future scaling
• • asynchronous processing and message queues
• • fault tolerance at every layer
• • phased device onboarding
• • built-in monitoring and operational tools from the start

This approach allows projects to start with a limited number of devices and scale to industrial levels without architectural changes.

Key Practical Conclusions

• • The main challenge in IoT is large-scale operation, not device connectivity
• • Reliability is more important than rapid deployment
• • Telemetry requires specialized storage architecture
• • Monitoring and alerting are mandatory components
• • The system architecture must account for device growth from the beginning

Payment systems belong to the category of mission-critical IT solutions. Unlike typical digital services, any failure here directly affects financial operations, settlements, and user trust.

At OneDev, we have worked with systems processing real financial transactions in a 24/7 environment. In practice, a payment platform is not a user interface or a mobile application. It is an infrastructure layer designed to process financial flows reliably under continuous load and ensure transaction accuracy.

Below is a practical engineering perspective on how production fintech platforms are built and operated.

Fintech Platform at the Architectural Level

In real-world environments, a fintech platform is a multi-layer transaction processing system built around reliability, data integrity, and continuous availability.

Core architectural responsibilities include:

• • receiving and routing payment requests
• • processing transactions and managing their states
• • ensuring idempotency of operations
• • synchronizing with external settlement systems
• • maintaining financial ledgers and operational logs

The key principle is simple: every transaction must either be completed correctly or safely declined. Loss or duplication of financial operations is unacceptable in a production system.

Core Components of a Payment Platform

Payment Gateways

Gateways handle incoming requests from external channels such as mobile applications, web services, terminals, and partner systems.

• • authentication and request validation
• • parameter verification
• • rate limiting
• • initial routing

Transaction Processing Core

The processing engine is responsible for:

• • financial business logic execution
• • transaction state management
• • fund reservation and confirmation
• • approval or rejection of operations
• • ensuring data consistency

Production systems rely on message queues, transaction logging, and retry mechanisms to ensure reliability.

Integration Layer

The platform interacts with multiple external financial and service systems. This layer must handle:

• • different protocols and data formats
• • timeouts and communication failures
• • retry and compensation mechanisms
• • asynchronous processing through queues

Monitoring and Operational Control

A production payment system always includes:

• • real-time transaction monitoring
• • alerting for delays and failures
• • queue and integration health tracking
• • operational dashboards for support teams

Reporting and Reconciliation

Financial infrastructure requires:

• • detailed transaction logs
• • daily reconciliation processes
• • operational and financial reporting
• • investigation tools for incident analysis

Why Reliability and Security Are Critical

• • service and database redundancy
• • horizontal scalability
• • full transaction logging and auditability
• • data encryption and secure communication channels
• • audit trails for users and system actions

In fintech environments, security is not a separate feature — it is a requirement across the entire architecture.

Real Load Patterns and Operational Challenges

Production payment systems experience uneven and sometimes extreme workloads:

• • peak hours and payout periods
• • bulk operations from partners
• • duplicate and repeated requests
• • latency or instability in external systems

Typical operational challenges include:

• • integration timeouts
• • duplicate transaction attempts
• • status inconsistencies
• • queue accumulation during peak periods

For this reason, the architecture must support retries, idempotency, and reliable state recovery.

Production Payment Systems vs. MVP

An MVP focuses on completing a transaction. A production platform must manage the full lifecycle of financial operations.

Key differences include:

• • complete auditability
• • reconciliation and reporting
• • error handling and recovery mechanisms
• • operational support tools
• • redundancy and high availability
• • protection against duplicates and retries

In practice, the main complexity lies not in executing a payment, but in handling exceptional scenarios correctly.

Fintech as Infrastructure

• • continuous 24/7 operation
• • scaling with transaction growth
• • adding new integrations without downtime
• • ensuring full transaction transparency

User interfaces may evolve. Processing reliability and architectural stability remain the foundation.

Practical Conclusions

• • The main complexity lies in handling failures and edge cases
• • Reliability is more important than development speed
• • Integrations consume a significant portion of project effort
• • Monitoring and operational visibility are mandatory
• • The architecture must be designed for future load growth

Industrial automation is increasingly viewed as an IT task. However, unlike corporate systems, the cost of failure here is significantly higher — production downtime, process disruption, or equipment damage.

At OneDev, we have worked with real industrial facilities and engineering infrastructure. In practice, such systems are not developed as typical software products, but as reliable digital environments that must operate continuously for many years.

Below is a practical perspective on industrial automation from the standpoint of an IT team involved in real-world implementations.

Industrial Automation in the IT Context

Traditionally, automation is associated with controllers, sensors, and production lines. In the IT context, it means building a digital monitoring and control layer on top of physical equipment.

The key functions of this layer include:

• • collecting data from equipment and sensors
• • visualizing industrial processes
• • real-time parameter monitoring
• • alerting on failures and deviations
• • storing historical data and enabling analytics

This creates a unified operational view of the entire facility — from individual devices to the full production site.

How SCADA and Monitoring Systems Work in Practice

In a production environment, SCADA is not a demonstration dashboard. It is a daily working tool for operators and engineers.

A typical system includes:

• • process diagrams (mimic panels)
• • real-time equipment data
• • event and alarm logs
• • threshold-based alerting
• • historical process data storage

Key operational requirements:

• • stable 24/7 operation
• • minimal data latency
• • clear and functional interface
• • redundancy and fault tolerance

In real environments, reliability and predictability are far more important than visual design.

Integration with Equipment and Sensors

The main challenge in industrial automation is not interface development, but integration with physical devices.

In practice, projects involve:

• • PLCs from different manufacturers
• • sensors and actuators
• • industrial protocols (Modbus, OPC, MQTT, etc.)
• • legacy equipment with limited documentation
• • unstable or low-bandwidth communication channels

Typical integration tasks include:

• • developing drivers and gateways
• • buffering data during communication outages
• • filtering and normalizing signals
• • time synchronization and event alignment

A significant portion of the project is carried out at the intersection of IT and industrial environments.

Why These Systems Cannot Be Built Quickly

Industrial projects are constrained by operational and technological limitations:

• • production cannot be stopped for testing
• • changes must follow strict operational procedures
• • every integration must be verified for safety
• • equipment may be decades old and have technical constraints

Implementation is usually performed in stages:

• • facility assessment
• • pilot deployment
• • gradual scaling
• • trial operation

In industrial environments, reliability always takes priority over speed.

Common Mistakes by Customers and Contractors

Trying to implement everything at once

• Lack of phased deployment increases risks and complicates commissioning.

Underestimating integration complexity

• The main effort lies in working with equipment, not building interfaces.

Focusing on visualization instead of reliability

• Well-designed dashboards cannot compensate for unstable data collection.

Lack of long-term architecture

• Systems must support future expansion and equipment modernization.

Why Automation Is Infrastructure, Not a Short-Term Project

In practice, such systems become:

• • a unified enterprise data layer
• • an operational platform for industrial processes
• • a foundation for analytics and optimization
• • a part of critical production infrastructure

User interfaces may change. Architecture and reliability must remain stable.

Key Practical Conclusions

• • The main challenge is equipment integration
• • Reliability is more important than implementation speed
• • Projects should be delivered in phases
• • Systems must operate 24/7
• • Architecture should be designed for long-term operation

In most cities, digital systems already exist. Cameras, sensors, utility systems, transport platforms, and citizen service tools are in place. However, they operate separately — across different departments, formats, and technologies.

The challenge is not the lack of technology. The challenge is fragmentation.

Without a unified platform, city management remains reactive: services learn about issues too late, decisions are made manually, and coordination between departments requires significant effort.

At OneDev, we have implemented city monitoring and management systems that operate 24/7 and are used daily by municipal services. These projects typically involve integrating dozens of data sources and departmental systems into a single operational infrastructure.

What a Smart City Platform Looks Like in Practice

In reality, a smart city is not a mobile app or a collection of sensors.

It is an infrastructure platform that:

• • collects data from multiple city systems
• • normalizes it into a unified format
• • detects events and anomalies
• • creates tasks for responsible services
• • tracks execution and response time

Platform Architecture

1. Data Collection Layer

City data sources are always heterogeneous:

• • departmental system APIs
• • IoT sensors and controllers
• • video streams
• • transport and utility systems
• • file-based data exchanges
• • legacy local applications

In practice, 60–70% of project time is spent on integrating data sources.

2. Processing and Normalization

• • data validation and cleansing
• • duplicate removal
• • format standardization
• • geolocation and mapping
• • aggregation by districts and assets
• • calculation of operational metrics

This layer forms a unified city data layer used by all higher-level services.

3. Event Management and Analytics

The system automatically detects operational events such as:

• • equipment failures
• • traffic congestion or overload
• • environmental threshold violations
• • increased citizen complaints in specific areas

Tasks are then assigned to responsible departments and monitored according to SLA.

4. Operational Dashboards

Interfaces are designed as working tools for dispatchers and managers:

• • city map with real-time asset status
• • active incident list
• • priorities and SLA tracking
• • department performance analytics
• • event history

In real operations, speed, clarity, and reliability are more important than visual effects.

5. Integrations

• • document management systems
• • citizen request platforms
• • dispatch and utility systems
• • regional and national platforms

Without bidirectional integration, the system becomes only a data showcase and does not support operational management.

Operational Value for the City

For city administration

• • execution control of tasks and directives
• • real-time monitoring of key indicators
• • operational analytics by districts and departments

For dispatch centers

• • a single window for incidents
• • faster response time
• • SLA and workload control

Practical outcomes

• • reduced incident response time
• • less manual coordination between departments
• • greater operational transparency
• • improved contractor performance control

Implementation Challenges

Heterogeneous and Legacy Systems

Many city systems lack modern APIs or operate unreliably. This is addressed through adapters, integration gateways, and asynchronous architecture.

Data Quality Issues

• • validation at the ingestion stage
• • automated quality checks
• • gradual improvement of data sources

Organizational Changes

• • pilot deployment in selected departments
• • phased rollout
• • establishing new operational procedures

Why a Smart City is Infrastructure

The OneDev Approach

• • audit of existing systems and data sources
• • phased implementation
• • modular and scalable architecture
• • integration without disrupting current operations
• post-launch support and continuous development