Robust storage and queuing system
Data packages as 'in-process data' are temporarily stored in our robust queuing system, depending on type transformation and chosen Alumio package into MySQL, Elastic, Apache spark, Google GCP or Amazon's Redshift.

They are used to guarantee processing at scale for all the individual pages of data in transit. If any system goes offline, the architecture above allows for elegantly pausing and resuming flow-processing activities without loss of data.

‍

Big Data  

Alumio is built as a high-performance integration platform to help external applications to be connected, and to handle big data. Data is transformed into smaller packages, called 'Alumio tasks' and can flow through our system in a scalable manner into externally connected applications via our API, supported by our robust queuing mechanism.

‍

Acknowledgement  

Data sent to Alumio listener APIs is only acknowledged after temporarily being persisted to redundant data storage and successfully queued. This protocol allows external applications to be certain that their data will be processed by a flow, or that it needs to be resent.

Authentication

Alumio can recognize expired or invalid API credentials and to automatically take connection resources offline. When a connection goes offline, Alumio's monitoring recognizes failed tasks. Additional workflows can be created to pause all related integration flows that are in progress. New flows will then, not be scheduled, and the offline connection will be placed into an automated recovery procedure. Then, once the connection comes back online, all related integration flows will resume processing where they left off, and new flows that did not run will be scheduled. 

‍

Health monitoring

Alumio health monitoring can recognize when integration flows miss their last scheduled run due to a downtime event. It will automatically re-schedule flows, which run immediately after the interruption has been resolved. 

Alumio has the resilience to recognize intermittent network errors and automatically retry them. 

Quality control

Alumio's monitoring can recognize field errors and, if additional health workflows are configured, automatically remove these fields from API retry requests so that critical integration flows do not fail due to field-level data errors.

Errors that cannot be automatically recovered are displayed on user-friendly dashboards, and customers can troubleshoot these errors for a certain period, for example, 30 days — including manually modifying and retrying failed records. 

Alumio supports a large number of configuration options to tune the performance of an integration flow. For example, you can control the data package size of data traveling through a flow, or the number of concurrent requests a specific connection is allowed to make at any given time. 

Integration flow scan also be set up to process only delta data such that external applications are not overwhelmed by large amounts of unchanged data being synced. 

Alumio’s iPaaS has no practical limits within a SMB Alumio private cloud account regarding:

• The number of applications that can be connected.
• The number of flows that can be defined.
• The number of flows that can run in parallel.
• The number of records that can be processed.
• The size of data that can be processed.

Alumio's limitations are based on the amount of request per minute (or second). As our enterprise application is horizontally and vertically scalable based on the given infrastructure, there are no limitations. 

See page infrastructure for more information about our SMB private cloud solution, which is default or our scalable enterprise solutions.