I am excited to share that members of the IgniteRealtime community will be heading to Brussels, Belgium, from January 29th to February 1st to take part in two important events for the open-source and real-time communications ecosystem: the annual XSF Summit and FOSDEM.

XSF Summit: Connecting the XMPP community

The XSF Summit , organized by the XMPP Standards Foundation, brings together developers, maintainers, and contributors from across the XMPP ecosystem. IgniteRealtime community members will be there to collaborate with peers, discuss the current state and future direction of XMPP, and share insights from ongoing IgniteRealtime projects.

These face-to-face discussions are invaluable for aligning on standards, exchanging implementation experience, and strengthening the relationships that keep open, decentralized communication thriving.

FOSDEM: Celebrating open source at scale

Following the XSF Summit, our community members will also attend FOSDEM (Free and Open source Software Developers’ European Meeting), one of the largest and most influential open-source conferences in the world.

FOSDEM is a unique opportunity to:

• Learn about the latest developments across a wide range of open-source technologies
• Meet contributors and users from diverse projects and communities
• Represent IgniteRealtime and real-time communication technologies within the broader open-source ecosystem

You’ll likely find us at the XMPP & Realtime Lounge (building AW, level 1).

Meet us in Brussels

If you’re attending the XSF Summit, FOSDEM, or will be in Brussels during this time, we’d love to connect. These events are a great chance to meet fellow IgniteRealtime users and contributors, exchange ideas, and talk about where we’re headed next.

We look forward to productive discussions, new connections, and bringing fresh energy and ideas back to the IgniteRealtime community. See you in Brussels!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

I am excited to share that members of the IgniteRealtime community will be heading to Brussels, Belgium, from January 29th to February 1st to take part in two important events for the open-source and real-time communications ecosystem: the annual XSF Summit and FOSDEM.

XSF Summit: Connecting the XMPP community

The XSF Summit , organized by the XMPP Standards Foundation, brings together developers, maintainers, and contributors from across the XMPP ecosystem. IgniteRealtime community members will be there to collaborate with peers, discuss the current state and future direction of XMPP, and share insights from ongoing IgniteRealtime projects.

These face-to-face discussions are invaluable for aligning on standards, exchanging implementation experience, and strengthening the relationships that keep open, decentralized communication thriving.

FOSDEM: Celebrating open source at scale

Following the XSF Summit, our community members will also attend FOSDEM (Free and Open source Software Developers’ European Meeting), one of the largest and most influential open-source conferences in the world.

FOSDEM is a unique opportunity to:

• Learn about the latest developments across a wide range of open-source technologies
• Meet contributors and users from diverse projects and communities
• Represent IgniteRealtime and real-time communication technologies within the broader open-source ecosystem

You’ll likely find us at the XMPP & Realtime Lounge (building AW, level 1).

Meet us in Brussels

If you’re attending the XSF Summit, FOSDEM, or will be in Brussels during this time, we’d love to connect. These events are a great chance to meet fellow IgniteRealtime users and contributors, exchange ideas, and talk about where we’re headed next.

We look forward to productive discussions, new connections, and bringing fresh energy and ideas back to the IgniteRealtime community. See you in Brussels!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

I am excited to share that members of the IgniteRealtime community will be heading to Brussels, Belgium, from January 29th to February 1st to take part in two important events for the open-source and real-time communications ecosystem: the annual XSF Summit and FOSDEM.

XSF Summit: Connecting the XMPP community

The XSF Summit , organized by the XMPP Standards Foundation, brings together developers, maintainers, and contributors from across the XMPP ecosystem. IgniteRealtime community members will be there to collaborate with peers, discuss the current state and future direction of XMPP, and share insights from ongoing IgniteRealtime projects.

These face-to-face discussions are invaluable for aligning on standards, exchanging implementation experience, and strengthening the relationships that keep open, decentralized communication thriving.

FOSDEM: Celebrating open source at scale

Following the XSF Summit, our community members will also attend FOSDEM (Free and Open source Software Developers’ European Meeting), one of the largest and most influential open-source conferences in the world.

FOSDEM is a unique opportunity to:

• Learn about the latest developments across a wide range of open-source technologies
• Meet contributors and users from diverse projects and communities
• Represent IgniteRealtime and real-time communication technologies within the broader open-source ecosystem

You’ll likely find us at the XMPP & Realtime Lounge (building AW, level 1).

Meet us in Brussels

If you’re attending the XSF Summit, FOSDEM, or will be in Brussels during this time, we’d love to connect. These events are a great chance to meet fellow IgniteRealtime users and contributors, exchange ideas, and talk about where we’re headed next.

We look forward to productive discussions, new connections, and bringing fresh energy and ideas back to the IgniteRealtime community. See you in Brussels!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

MongooseIM 6.5: Open for Integration is now available. This release focuses on easier integration with your applications while continuing to deliver a scalable and reliable XMPP-based messaging server.

For such integration, you can use the Admin or User GraphQL API. Another example is the interaction of MongooseIM with a database. A relational DB such as PostgreSQL, MySQL or CockroachDB can be used to store user accounts, message archives, multi-user chatrooms, publish-subscribe nodes, cluster nodes and much more. Other supported databases and storage services include Cassandra or Elastic Search for message archive, Redis for user sessions and LDAP for authentication.

You can see the complete list in our documentation.
There is another important way to let MongooseIM interact with your distributed system: event pushing . The core of this functionality is the event pusher module, which can push selected events to services like Amazon SNS , RabbitMQ or MongoosePush . In the most recent release 6.5.0, we have improved the event pushing mechanism, focusing on better integration with RabbitMQ.

Event pushing in MongooseIM 6.5.0

The diagram below explains the event pushing architecture in the latest version of MongooseIM:

Events utilize the concept of hooks and handlers . Currently, events are triggered for a few selected hooks, e.g. when a user logs in/out or sends/receives a message. There are almost 140 different hooks defined in MongooseIM though, so there is much room for adding custom events. A module called mod_event_pusher_hook_translator handles the selected hooks, creating events and passing them to the main event pusher API function, mod_event_pusher:push_event/2 .

Then, a hook called push_event is triggered, leveraging the hooks-and-handlers mechanism for the second time. This hook is handled by configurable service-specific backend modules, such as:

• sns – for sending notifications to Amazon SNS,
• rabbit – for sending notifications to RabbitMQ or CloudAMQP,
• http – for sending notifications to a custom service,
• push – for sending push notifications to mobile devices with the help of MongoosePush.

These modules act as interfaces to the corresponding external services. A key feature of this design is its extensibility. For example, one can easily add a kafka backend module that would deliver the events to Apache Kafka as shown on the diagram above.

Push notifications

Let’s focus on the push module as it is a bit more complex. In general, it uses hooks and handlers once again – the push_notifications hook in particular. In order to actually deliver push notifications to a mobile device, a module called mod_push_service_mongoosepush handles that hook by sending the notifications to a separate service called MongoosePush . Finally, MongoosePush will dispatch the notification request and send the notifications to configured services such as APNs or Google FCM .

Each stage of this process is configurable and extensible. Firstly, we have assumed that a virtual pubsub host is used, but there is also an option to use a separate pubsub node for push notifications as described in XEP-0357: Push Notifications , adding another step before running the push_notifications hook. Speaking about that hook, you can implement your own module handling it by calling your own service instead of MongoosePush. Additionally, if you need to extend the notification logic with additional filtering and processing, you can implement a plugin module to mod_event_pusher_push .

Pushing events to RabbitMQ

As the RabbitMQ backend module was improved and made production-ready in version 6.5.0, let’s use it as an example of how you can easily configure MongooseIM to push events to RabbitMQ. The simplest way to demonstrate this is with Docker containers. Firstly, we need a container for RabbitMQ:

docker network create example
docker run --rm -d --network example --name rabbit rabbitmq:management

The management tag is used because we will need the rabbitmqadmin command. The default port 5672 will be used by MongooseIM. The connection is unencrypted for simplicity, but it is recommended to use TLS in a production environment.

As the next step, let’s obtain the default mongooseim.toml configuration file from the MongooseIM 6.5.0 image:

docker create --name mongooseim erlangsolutions/mongooseim:6.5.0
docker cp mongooseim:/usr/lib/mongooseim/etc/mongooseim.toml .
docker rm mongooseim

This default configuration file uses the Mnesia internal database. Although we recommend using CETS and a relational database instead of Mnesia, in this example we will try to keep it as simple as possible – so you only need to add the following to mongooseim.toml :

[outgoing_pools.rabbit.event_pusher]
  connection.host = "rabbit"

[modules.mod_event_pusher.rabbit]
  chat_msg_exchange = {}

The first section configures a pool of connections to RabbitMQ with the default settings , while the second one enables the event pusher module with the rabbit backend, and includes chat_msg_exchange in order to enable the exchange for one-to-one chat messages (called chat_msg by default – see all options ). If you are wondering where to add these lines to mongooseim.toml – you can put them anywhere, but it is recommended to group them by section (e.g. outgoing_pools, modules etc.) for readability.

Having the configuration file ready, we can start the MongooseIM container:

docker run --rm -d --network example -e JOIN_CLUSTER=false \
  -v ./mongooseim.toml:/usr/lib/mongooseim/etc/mongooseim.toml \
  --name mongooseim erlangsolutions/mongooseim:6.5.0

After it starts, the chat_msg exchange should be automatically created in RabbitMQ. In order to see its messages, we need to bind a queue to it.

docker exec -it rabbit rabbitmqadmin declare queue --name recv
docker exec -it rabbit rabbitmqadmin declare binding --source chat_msg --destination recv --destination-type queue --routing-key "*.chat_msg_recv"

The routing key *.chat_msg_recv means that only the events for received messages will be routed – in this example we skip all events for sent messages. Now let’s create two user accounts in MongooseIM:

docker exec -it mongooseim mongooseimctl account registerUser --username alice --domain localhost --password secret
docker exec -it mongooseim mongooseimctl account registerUser --username bob --domain localhost --password secret

You should get the “User … successfully registered” message for each of them. Next, send the message from alice to bob – we could do that with an XMPP client , but the simplest way here is to use the admin CLI:

docker exec -it mongooseim mongooseimctl stanza sendMessage --from alice@localhost --to bob@localhost --body hello

Now we can check if the message event was sent to our RabbitMQ queue:

docker exec -it rabbit rabbitmqadmin get messages --queue recv

The payload should be:

{"to_user_id": "bob@localhost", "from_user_id": "alice@localhost", "message": "hello"}

This simple example shows how easy it is to extend the functionality of MongooseIM beyond XMPP – as soon as you have the events in a message queue like RabbitMQ, you can perform various actions on them such as calculating statistics for billing purposes, performing analytics or storing them in an external database separate from MongooseIM.

Summary

The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself, but of course don’t hesitate to contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and – if necessary – customise it to fit your particular needs. For more information about the latest improvements, see the release notes .

The post MongooseIM 6.5: Open for Integration appeared first on Erlang Solutions .

MongooseIM 6.5: Open for Integration is now available. This release focuses on easier integration with your applications while continuing to deliver a scalable and reliable XMPP-based messaging server.

For such integration, you can use the Admin or User GraphQL API. Another example is the interaction of MongooseIM with a database. A relational DB such as PostgreSQL, MySQL or CockroachDB can be used to store user accounts, message archives, multi-user chatrooms, publish-subscribe nodes, cluster nodes and much more. Other supported databases and storage services include Cassandra or Elastic Search for message archive, Redis for user sessions and LDAP for authentication.

You can see the complete list in our documentation.
There is another important way to let MongooseIM interact with your distributed system: event pushing . The core of this functionality is the event pusher module, which can push selected events to services like Amazon SNS , RabbitMQ or MongoosePush . In the most recent release 6.5.0, we have improved the event pushing mechanism, focusing on better integration with RabbitMQ.

Event pushing in MongooseIM 6.5.0

The diagram below explains the event pushing architecture in the latest version of MongooseIM:

Events utilize the concept of hooks and handlers . Currently, events are triggered for a few selected hooks, e.g. when a user logs in/out or sends/receives a message. There are almost 140 different hooks defined in MongooseIM though, so there is much room for adding custom events. A module called mod_event_pusher_hook_translator handles the selected hooks, creating events and passing them to the main event pusher API function, mod_event_pusher:push_event/2 .

Then, a hook called push_event is triggered, leveraging the hooks-and-handlers mechanism for the second time. This hook is handled by configurable service-specific backend modules, such as:

• sns – for sending notifications to Amazon SNS,
• rabbit – for sending notifications to RabbitMQ or CloudAMQP,
• http – for sending notifications to a custom service,
• push – for sending push notifications to mobile devices with the help of MongoosePush.

These modules act as interfaces to the corresponding external services. A key feature of this design is its extensibility. For example, one can easily add a kafka backend module that would deliver the events to Apache Kafka as shown on the diagram above.

Push notifications

Let’s focus on the push module as it is a bit more complex. In general, it uses hooks and handlers once again – the push_notifications hook in particular. In order to actually deliver push notifications to a mobile device, a module called mod_push_service_mongoosepush handles that hook by sending the notifications to a separate service called MongoosePush . Finally, MongoosePush will dispatch the notification request and send the notifications to configured services such as APNs or Google FCM .

Each stage of this process is configurable and extensible. Firstly, we have assumed that a virtual pubsub host is used, but there is also an option to use a separate pubsub node for push notifications as described in XEP-0357: Push Notifications , adding another step before running the push_notifications hook. Speaking about that hook, you can implement your own module handling it by calling your own service instead of MongoosePush. Additionally, if you need to extend the notification logic with additional filtering and processing, you can implement a plugin module to mod_event_pusher_push .

Pushing events to RabbitMQ

As the RabbitMQ backend module was improved and made production-ready in version 6.5.0, let’s use it as an example of how you can easily configure MongooseIM to push events to RabbitMQ. The simplest way to demonstrate this is with Docker containers. Firstly, we need a container for RabbitMQ:

docker network create example
docker run --rm -d --network example --name rabbit rabbitmq:management

The management tag is used because we will need the rabbitmqadmin command. The default port 5672 will be used by MongooseIM. The connection is unencrypted for simplicity, but it is recommended to use TLS in a production environment.

As the next step, let’s obtain the default mongooseim.toml configuration file from the MongooseIM 6.5.0 image:

docker create --name mongooseim erlangsolutions/mongooseim:6.5.0
docker cp mongooseim:/usr/lib/mongooseim/etc/mongooseim.toml .
docker rm mongooseim

This default configuration file uses the Mnesia internal database. Although we recommend using CETS and a relational database instead of Mnesia, in this example we will try to keep it as simple as possible – so you only need to add the following to mongooseim.toml :

[outgoing_pools.rabbit.event_pusher]
  connection.host = "rabbit"

[modules.mod_event_pusher.rabbit]
  chat_msg_exchange = {}

The first section configures a pool of connections to RabbitMQ with the default settings , while the second one enables the event pusher module with the rabbit backend, and includes chat_msg_exchange in order to enable the exchange for one-to-one chat messages (called chat_msg by default – see all options ). If you are wondering where to add these lines to mongooseim.toml – you can put them anywhere, but it is recommended to group them by section (e.g. outgoing_pools, modules etc.) for readability.

Having the configuration file ready, we can start the MongooseIM container:

docker run --rm -d --network example -e JOIN_CLUSTER=false \
  -v ./mongooseim.toml:/usr/lib/mongooseim/etc/mongooseim.toml \
  --name mongooseim erlangsolutions/mongooseim:6.5.0

After it starts, the chat_msg exchange should be automatically created in RabbitMQ. In order to see its messages, we need to bind a queue to it.

docker exec -it rabbit rabbitmqadmin declare queue --name recv
docker exec -it rabbit rabbitmqadmin declare binding --source chat_msg --destination recv --destination-type queue --routing-key "*.chat_msg_recv"

The routing key *.chat_msg_recv means that only the events for received messages will be routed – in this example we skip all events for sent messages. Now let’s create two user accounts in MongooseIM:

docker exec -it mongooseim mongooseimctl account registerUser --username alice --domain localhost --password secret
docker exec -it mongooseim mongooseimctl account registerUser --username bob --domain localhost --password secret

You should get the “User … successfully registered” message for each of them. Next, send the message from alice to bob – we could do that with an XMPP client , but the simplest way here is to use the admin CLI:

docker exec -it mongooseim mongooseimctl stanza sendMessage --from alice@localhost --to bob@localhost --body hello

Now we can check if the message event was sent to our RabbitMQ queue:

docker exec -it rabbit rabbitmqadmin get messages --queue recv

The payload should be:

{"to_user_id": "bob@localhost", "from_user_id": "alice@localhost", "message": "hello"}

This simple example shows how easy it is to extend the functionality of MongooseIM beyond XMPP – as soon as you have the events in a message queue like RabbitMQ, you can perform various actions on them such as calculating statistics for billing purposes, performing analytics or storing them in an external database separate from MongooseIM.

Summary

The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself, but of course don’t hesitate to contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and – if necessary – customise it to fit your particular needs. For more information about the latest improvements, see the release notes .

The post MongooseIM 6.5: Open for Integration appeared first on Erlang Solutions .

MongooseIM 6.5: Open for Integration is now available. This release focuses on easier integration with your applications while continuing to deliver a scalable and reliable XMPP-based messaging server.

For such integration, you can use the Admin or User GraphQL API. Another example is the interaction of MongooseIM with a database. A relational DB such as PostgreSQL, MySQL or CockroachDB can be used to store user accounts, message archives, multi-user chatrooms, publish-subscribe nodes, cluster nodes and much more. Other supported databases and storage services include Cassandra or Elastic Search for message archive, Redis for user sessions and LDAP for authentication.

You can see the complete list in our documentation.
There is another important way to let MongooseIM interact with your distributed system: event pushing . The core of this functionality is the event pusher module, which can push selected events to services like Amazon SNS , RabbitMQ or MongoosePush . In the most recent release 6.5.0, we have improved the event pushing mechanism, focusing on better integration with RabbitMQ.

Event pushing in MongooseIM 6.5.0

The diagram below explains the event pushing architecture in the latest version of MongooseIM:

Events utilize the concept of hooks and handlers . Currently, events are triggered for a few selected hooks, e.g. when a user logs in/out or sends/receives a message. There are almost 140 different hooks defined in MongooseIM though, so there is much room for adding custom events. A module called mod_event_pusher_hook_translator handles the selected hooks, creating events and passing them to the main event pusher API function, mod_event_pusher:push_event/2 .

Then, a hook called push_event is triggered, leveraging the hooks-and-handlers mechanism for the second time. This hook is handled by configurable service-specific backend modules, such as:

• sns – for sending notifications to Amazon SNS,
• rabbit – for sending notifications to RabbitMQ or CloudAMQP,
• http – for sending notifications to a custom service,
• push – for sending push notifications to mobile devices with the help of MongoosePush.

These modules act as interfaces to the corresponding external services. A key feature of this design is its extensibility. For example, one can easily add a kafka backend module that would deliver the events to Apache Kafka as shown on the diagram above.

Push notifications

Let’s focus on the push module as it is a bit more complex. In general, it uses hooks and handlers once again – the push_notifications hook in particular. In order to actually deliver push notifications to a mobile device, a module called mod_push_service_mongoosepush handles that hook by sending the notifications to a separate service called MongoosePush . Finally, MongoosePush will dispatch the notification request and send the notifications to configured services such as APNs or Google FCM .

Each stage of this process is configurable and extensible. Firstly, we have assumed that a virtual pubsub host is used, but there is also an option to use a separate pubsub node for push notifications as described in XEP-0357: Push Notifications , adding another step before running the push_notifications hook. Speaking about that hook, you can implement your own module handling it by calling your own service instead of MongoosePush. Additionally, if you need to extend the notification logic with additional filtering and processing, you can implement a plugin module to mod_event_pusher_push .

Pushing events to RabbitMQ

As the RabbitMQ backend module was improved and made production-ready in version 6.5.0, let’s use it as an example of how you can easily configure MongooseIM to push events to RabbitMQ. The simplest way to demonstrate this is with Docker containers. Firstly, we need a container for RabbitMQ:

docker network create example
docker run --rm -d --network example --name rabbit rabbitmq:management

The management tag is used because we will need the rabbitmqadmin command. The default port 5672 will be used by MongooseIM. The connection is unencrypted for simplicity, but it is recommended to use TLS in a production environment.

As the next step, let’s obtain the default mongooseim.toml configuration file from the MongooseIM 6.5.0 image:

docker create --name mongooseim erlangsolutions/mongooseim:6.5.0
docker cp mongooseim:/usr/lib/mongooseim/etc/mongooseim.toml .
docker rm mongooseim

This default configuration file uses the Mnesia internal database. Although we recommend using CETS and a relational database instead of Mnesia, in this example we will try to keep it as simple as possible – so you only need to add the following to mongooseim.toml :

[outgoing_pools.rabbit.event_pusher]
  connection.host = "rabbit"

[modules.mod_event_pusher.rabbit]
  chat_msg_exchange = {}

The first section configures a pool of connections to RabbitMQ with the default settings , while the second one enables the event pusher module with the rabbit backend, and includes chat_msg_exchange in order to enable the exchange for one-to-one chat messages (called chat_msg by default – see all options ). If you are wondering where to add these lines to mongooseim.toml – you can put them anywhere, but it is recommended to group them by section (e.g. outgoing_pools, modules etc.) for readability.

Having the configuration file ready, we can start the MongooseIM container:

docker run --rm -d --network example -e JOIN_CLUSTER=false \
  -v ./mongooseim.toml:/usr/lib/mongooseim/etc/mongooseim.toml \
  --name mongooseim erlangsolutions/mongooseim:6.5.0

After it starts, the chat_msg exchange should be automatically created in RabbitMQ. In order to see its messages, we need to bind a queue to it.

docker exec -it rabbit rabbitmqadmin declare queue --name recv
docker exec -it rabbit rabbitmqadmin declare binding --source chat_msg --destination recv --destination-type queue --routing-key "*.chat_msg_recv"

The routing key *.chat_msg_recv means that only the events for received messages will be routed – in this example we skip all events for sent messages. Now let’s create two user accounts in MongooseIM:

docker exec -it mongooseim mongooseimctl account registerUser --username alice --domain localhost --password secret
docker exec -it mongooseim mongooseimctl account registerUser --username bob --domain localhost --password secret

You should get the “User … successfully registered” message for each of them. Next, send the message from alice to bob – we could do that with an XMPP client , but the simplest way here is to use the admin CLI:

docker exec -it mongooseim mongooseimctl stanza sendMessage --from alice@localhost --to bob@localhost --body hello

Now we can check if the message event was sent to our RabbitMQ queue:

docker exec -it rabbit rabbitmqadmin get messages --queue recv

The payload should be:

{"to_user_id": "bob@localhost", "from_user_id": "alice@localhost", "message": "hello"}

This simple example shows how easy it is to extend the functionality of MongooseIM beyond XMPP – as soon as you have the events in a message queue like RabbitMQ, you can perform various actions on them such as calculating statistics for billing purposes, performing analytics or storing them in an external database separate from MongooseIM.

Summary

The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself, but of course don’t hesitate to contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and – if necessary – customise it to fit your particular needs. For more information about the latest improvements, see the release notes .

The post MongooseIM 6.5: Open for Integration appeared first on Erlang Solutions .

​​We are living in an economy that rarely sleeps. Payments clear late at night. Payroll runs in the background. Businesses expect every digital touchpoint to work when they need it.

Most people do not think about this shift. They assume the systems behind it will hold.

That assumption carries weight.

Fintechs, including small and mid-sized ones, now sit inside the basic infrastructure of how money moves. Their uptime affects cash flow. Their stability affects trust. When something breaks, real businesses feel it immediately.

Expectations changed faster than most systems did.This follows on from our earlier piece, From Prototype to Production , which explored how early technical shortcuts surface as systems scale. Here, we look at what happens next, when those systems become part of the infrastructure businesses rely on every day.

When “tech downtime” becomes infrastructure failure

Outages no longer feel contained. A single failure can affect services that millions of people and businesses depend on.

Large providers experience this as much as small ones. When a shared platform falters, the impact spreads quickly. More than 60 percent of outages now come from third-party providers rather than internal systems, highlighting how tightly connected the ecosystem has become.

The true cost is trust

For fintechs, the impact is immediate because money is involved.

A payment delay blocks cash flow. A failed identity check stops onboarding. A stalled platform damages credibility.

For an SME, this can play out over the course of a single day. Payroll does not process in the morning. Supplier payments stall in the afternoon. Customer support queues fill up while teams wait for systems to recover. Even short interruptions create knock-on effects that last far longer than the outage itself.

And the numbers reflect that risk:

• £25,000 is the average cost of downtime for SMEs.
• 40% of customers consider switching providers after a single outage.
• Fintech revenue losses account for approximately US$37 million of downtime-related costs each year.
  

At this level of dependency, downtime stops being a technical issue. It becomes an infrastructure failure.

Fintechs have become infrastructure whether they intended to or not

Fintech services have moved beyond convenience. They now underpin everyday economic activity for businesses that depend on constant access to money, credit, and financial data.

This shift shows up in uptime expectations. Platforms that handle financial activity are measured against standards once reserved for mission-critical systems. Even brief disruption can have outsized consequences when services are expected to remain available throughout the day..

Customers do not adjust expectations based on company size or stage. If money flows through a service, users expect it to be available around the clock. When it is not, the failure feels systemic rather than technical. What breaks is not just functionality, but confidence.

That is the environment fintech leaders are operating in now.

Where resilience typically breaks down

Most fintech systems do not fail because the idea was weak. They fail because early decisions prioritised speed over durability.

Teams optimise for launch. They prove demand. They ship quickly. That works early on, but systems designed for experimentation often struggle once demand becomes constant rather than occasional.

Shortcuts that felt harmless early on start to surface under pressure. Shared components become bottlenecks. Manual processes turn into operational risk. Integrations that worked at low volume become fragile at scale. Recent analysis shows average API uptime has fallen year over year, adding more than 18 hours of downtime annually for systems dependent on third-party APIs.

Common pressure points include:

• Shared components that act as single points of failure
  
• Manual operational work that cannot keep up with growth
  
• Third-party dependencies with limited visibility or control
  
• Architecture built for bursts of usage instead of continuous demand
  

These are not accidental outcomes. They are the result of trade-offs made under pressure. Funding milestones, launch timelines, and growth targets shape architecture as much as technical skill does.

When outages happen, they rarely trace back to a single bug. They trace back to earlier choices about what mattered and what could wait.

From product thinking to infrastructure grade systems

Product thinking is about features and speed. Infrastructure thinking is about continuity.

Infrastructure-grade systems assume failure will happen. They are built to contain it, recover quickly, and keep the wider platform running. The goal is not perfection. The goal is staying available.

The goal is not perfection. The goal is staying available.

Continuous availability is now expected in financial services. Systems are updated and maintained without noticeable downtime because users do not tolerate interruptions when money is involved.

This approach does not slow teams down. It reduces risk. Deployments feel routine instead of stressful. Engineering effort shifts away from incident response and toward steady improvement.

Over time, this changes how organisations operate. Teams plan differently. Roadmaps become more realistic. Reliability becomes part of delivery rather than a separate concern.

Elixir and the always-on economy

Elixir programming language is designed for systems that are expected to stay available. It runs on the BEAM virtual machine, which was built in environments where downtime carried real consequences.

That background shows up in how Elixir applications are structured. Systems are composed of many small, isolated processes rather than large, tightly coupled components. When something fails, it fails locally. Recovery is expected. The wider system continues to operate.

Elixir in Fintech

This matters in fintech, where failure is inevitable and interruptions are costly. External services misbehave. Load changes without warning. Elixir applications are built to absorb those conditions and recover quickly without cascading outages.

Teams working in Elixir tend to spend less time managing fragile behaviour and more time improving core functionality. Systems evolve instead of being replaced. Reliability becomes part of the foundation rather than a promise teams struggle to maintain.

For fintechs operating in an always-on economy, that approach aligns with the expectations already placed on them.

Reliability as a competitive advantage

Reliable systems can completely change how a fintech operates day to day.

For growing fintechs, uptime supports trust and regulatory confidence. Customers stay because the platform behaves predictably. Growth becomes steadier because teams are not constantly reacting to incidents. Downtime costs make this real, especially for small businesses that lose revenue when systems are unavailable.

For larger providers, reliability reduces operational strain. Fewer incidents mean fewer emergency fixes and fewer difficult conversations with partners and regulators. Teams spend more time improving core services and less time managing fallout.

Reliability also shapes perception. Platforms that stay up become easier to trust with deeper integrations and higher volumes. Over time, that trust compounds and turns stability into a real advantage, even if it is rarely visible from the outside.

To conclude

The always-on economy creates real opportunity for fintechs, but it also raises expectations that many platforms were not originally built to meet.

The question is whether your system has the resilience to operate as infrastructure day after day. If you are a fintech and want to build with reliability in mind, get in touch .

Designing for resilience early makes it far easier to scale without introducing fragility later on.

The post The Always-On Economy: Fintech as Critical Infrastructure appeared first on Erlang Solutions .

​​We are living in an economy that rarely sleeps. Payments clear late at night. Payroll runs in the background. Businesses expect every digital touchpoint to work when they need it.

Most people do not think about this shift. They assume the systems behind it will hold.

That assumption carries weight.

Fintechs, including small and mid-sized ones, now sit inside the basic infrastructure of how money moves. Their uptime affects cash flow. Their stability affects trust. When something breaks, real businesses feel it immediately.

Expectations changed faster than most systems did.This follows on from our earlier piece, From Prototype to Production , which explored how early technical shortcuts surface as systems scale. Here, we look at what happens next, when those systems become part of the infrastructure businesses rely on every day.

When “tech downtime” becomes infrastructure failure

Outages no longer feel contained. A single failure can affect services that millions of people and businesses depend on.

Large providers experience this as much as small ones. When a shared platform falters, the impact spreads quickly. More than 60 percent of outages now come from third-party providers rather than internal systems, highlighting how tightly connected the ecosystem has become.

The true cost is trust

For fintechs, the impact is immediate because money is involved.

A payment delay blocks cash flow. A failed identity check stops onboarding. A stalled platform damages credibility.

For an SME, this can play out over the course of a single day. Payroll does not process in the morning. Supplier payments stall in the afternoon. Customer support queues fill up while teams wait for systems to recover. Even short interruptions create knock-on effects that last far longer than the outage itself.

And the numbers reflect that risk:

• £25,000 is the average cost of downtime for SMEs.
• 40% of customers consider switching providers after a single outage.
• Fintech revenue losses account for approximately US$37 million of downtime-related costs each year.
  

At this level of dependency, downtime stops being a technical issue. It becomes an infrastructure failure.

Fintechs have become infrastructure whether they intended to or not

Fintech services have moved beyond convenience. They now underpin everyday economic activity for businesses that depend on constant access to money, credit, and financial data.

This shift shows up in uptime expectations. Platforms that handle financial activity are measured against standards once reserved for mission-critical systems. Even brief disruption can have outsized consequences when services are expected to remain available throughout the day..

Customers do not adjust expectations based on company size or stage. If money flows through a service, users expect it to be available around the clock. When it is not, the failure feels systemic rather than technical. What breaks is not just functionality, but confidence.

That is the environment fintech leaders are operating in now.

Where resilience typically breaks down

Most fintech systems do not fail because the idea was weak. They fail because early decisions prioritised speed over durability.

Teams optimise for launch. They prove demand. They ship quickly. That works early on, but systems designed for experimentation often struggle once demand becomes constant rather than occasional.

Shortcuts that felt harmless early on start to surface under pressure. Shared components become bottlenecks. Manual processes turn into operational risk. Integrations that worked at low volume become fragile at scale. Recent analysis shows average API uptime has fallen year over year, adding more than 18 hours of downtime annually for systems dependent on third-party APIs.

Common pressure points include:

• Shared components that act as single points of failure
  
• Manual operational work that cannot keep up with growth
  
• Third-party dependencies with limited visibility or control
  
• Architecture built for bursts of usage instead of continuous demand
  

These are not accidental outcomes. They are the result of trade-offs made under pressure. Funding milestones, launch timelines, and growth targets shape architecture as much as technical skill does.

When outages happen, they rarely trace back to a single bug. They trace back to earlier choices about what mattered and what could wait.

From product thinking to infrastructure grade systems

Product thinking is about features and speed. Infrastructure thinking is about continuity.

Infrastructure-grade systems assume failure will happen. They are built to contain it, recover quickly, and keep the wider platform running. The goal is not perfection. The goal is staying available.

The goal is not perfection. The goal is staying available.

Continuous availability is now expected in financial services. Systems are updated and maintained without noticeable downtime because users do not tolerate interruptions when money is involved.

This approach does not slow teams down. It reduces risk. Deployments feel routine instead of stressful. Engineering effort shifts away from incident response and toward steady improvement.

Over time, this changes how organisations operate. Teams plan differently. Roadmaps become more realistic. Reliability becomes part of delivery rather than a separate concern.

Elixir and the always-on economy

Elixir programming language is designed for systems that are expected to stay available. It runs on the BEAM virtual machine, which was built in environments where downtime carried real consequences.

That background shows up in how Elixir applications are structured. Systems are composed of many small, isolated processes rather than large, tightly coupled components. When something fails, it fails locally. Recovery is expected. The wider system continues to operate.

Elixir in Fintech

This matters in fintech, where failure is inevitable and interruptions are costly. External services misbehave. Load changes without warning. Elixir applications are built to absorb those conditions and recover quickly without cascading outages.

Teams working in Elixir tend to spend less time managing fragile behaviour and more time improving core functionality. Systems evolve instead of being replaced. Reliability becomes part of the foundation rather than a promise teams struggle to maintain.

For fintechs operating in an always-on economy, that approach aligns with the expectations already placed on them.

Reliability as a competitive advantage

Reliable systems can completely change how a fintech operates day to day.

For growing fintechs, uptime supports trust and regulatory confidence. Customers stay because the platform behaves predictably. Growth becomes steadier because teams are not constantly reacting to incidents. Downtime costs make this real, especially for small businesses that lose revenue when systems are unavailable.

For larger providers, reliability reduces operational strain. Fewer incidents mean fewer emergency fixes and fewer difficult conversations with partners and regulators. Teams spend more time improving core services and less time managing fallout.

Reliability also shapes perception. Platforms that stay up become easier to trust with deeper integrations and higher volumes. Over time, that trust compounds and turns stability into a real advantage, even if it is rarely visible from the outside.

To conclude

The always-on economy creates real opportunity for fintechs, but it also raises expectations that many platforms were not originally built to meet.

The question is whether your system has the resilience to operate as infrastructure day after day. If you are a fintech and want to build with reliability in mind, get in touch .

Designing for resilience early makes it far easier to scale without introducing fragility later on.

The post The Always-On Economy: Fintech as Critical Infrastructure appeared first on Erlang Solutions .

​​We are living in an economy that rarely sleeps. Payments clear late at night. Payroll runs in the background. Businesses expect every digital touchpoint to work when they need it.

Most people do not think about this shift. They assume the systems behind it will hold.

That assumption carries weight.

Fintechs, including small and mid-sized ones, now sit inside the basic infrastructure of how money moves. Their uptime affects cash flow. Their stability affects trust. When something breaks, real businesses feel it immediately.

Expectations changed faster than most systems did.This follows on from our earlier piece, From Prototype to Production , which explored how early technical shortcuts surface as systems scale. Here, we look at what happens next, when those systems become part of the infrastructure businesses rely on every day.

When “tech downtime” becomes infrastructure failure

Outages no longer feel contained. A single failure can affect services that millions of people and businesses depend on.

Large providers experience this as much as small ones. When a shared platform falters, the impact spreads quickly. More than 60 percent of outages now come from third-party providers rather than internal systems, highlighting how tightly connected the ecosystem has become.

The true cost is trust

For fintechs, the impact is immediate because money is involved.

A payment delay blocks cash flow. A failed identity check stops onboarding. A stalled platform damages credibility.

For an SME, this can play out over the course of a single day. Payroll does not process in the morning. Supplier payments stall in the afternoon. Customer support queues fill up while teams wait for systems to recover. Even short interruptions create knock-on effects that last far longer than the outage itself.

And the numbers reflect that risk:

• £25,000 is the average cost of downtime for SMEs.
• 40% of customers consider switching providers after a single outage.
• Fintech revenue losses account for approximately US$37 million of downtime-related costs each year.
  

At this level of dependency, downtime stops being a technical issue. It becomes an infrastructure failure.

Fintechs have become infrastructure whether they intended to or not

Fintech services have moved beyond convenience. They now underpin everyday economic activity for businesses that depend on constant access to money, credit, and financial data.

This shift shows up in uptime expectations. Platforms that handle financial activity are measured against standards once reserved for mission-critical systems. Even brief disruption can have outsized consequences when services are expected to remain available throughout the day..

Customers do not adjust expectations based on company size or stage. If money flows through a service, users expect it to be available around the clock. When it is not, the failure feels systemic rather than technical. What breaks is not just functionality, but confidence.

That is the environment fintech leaders are operating in now.

Where resilience typically breaks down

Most fintech systems do not fail because the idea was weak. They fail because early decisions prioritised speed over durability.

Teams optimise for launch. They prove demand. They ship quickly. That works early on, but systems designed for experimentation often struggle once demand becomes constant rather than occasional.

Shortcuts that felt harmless early on start to surface under pressure. Shared components become bottlenecks. Manual processes turn into operational risk. Integrations that worked at low volume become fragile at scale. Recent analysis shows average API uptime has fallen year over year, adding more than 18 hours of downtime annually for systems dependent on third-party APIs.

Common pressure points include:

• Shared components that act as single points of failure
  
• Manual operational work that cannot keep up with growth
  
• Third-party dependencies with limited visibility or control
  
• Architecture built for bursts of usage instead of continuous demand
  

These are not accidental outcomes. They are the result of trade-offs made under pressure. Funding milestones, launch timelines, and growth targets shape architecture as much as technical skill does.

When outages happen, they rarely trace back to a single bug. They trace back to earlier choices about what mattered and what could wait.

From product thinking to infrastructure grade systems

Product thinking is about features and speed. Infrastructure thinking is about continuity.

Infrastructure-grade systems assume failure will happen. They are built to contain it, recover quickly, and keep the wider platform running. The goal is not perfection. The goal is staying available.

The goal is not perfection. The goal is staying available.

Continuous availability is now expected in financial services. Systems are updated and maintained without noticeable downtime because users do not tolerate interruptions when money is involved.

This approach does not slow teams down. It reduces risk. Deployments feel routine instead of stressful. Engineering effort shifts away from incident response and toward steady improvement.

Over time, this changes how organisations operate. Teams plan differently. Roadmaps become more realistic. Reliability becomes part of delivery rather than a separate concern.

Elixir and the always-on economy

Elixir programming language is designed for systems that are expected to stay available. It runs on the BEAM virtual machine, which was built in environments where downtime carried real consequences.

That background shows up in how Elixir applications are structured. Systems are composed of many small, isolated processes rather than large, tightly coupled components. When something fails, it fails locally. Recovery is expected. The wider system continues to operate.

Elixir in Fintech

This matters in fintech, where failure is inevitable and interruptions are costly. External services misbehave. Load changes without warning. Elixir applications are built to absorb those conditions and recover quickly without cascading outages.

Teams working in Elixir tend to spend less time managing fragile behaviour and more time improving core functionality. Systems evolve instead of being replaced. Reliability becomes part of the foundation rather than a promise teams struggle to maintain.

For fintechs operating in an always-on economy, that approach aligns with the expectations already placed on them.

Reliability as a competitive advantage

Reliable systems can completely change how a fintech operates day to day.

For growing fintechs, uptime supports trust and regulatory confidence. Customers stay because the platform behaves predictably. Growth becomes steadier because teams are not constantly reacting to incidents. Downtime costs make this real, especially for small businesses that lose revenue when systems are unavailable.

For larger providers, reliability reduces operational strain. Fewer incidents mean fewer emergency fixes and fewer difficult conversations with partners and regulators. Teams spend more time improving core services and less time managing fallout.

Reliability also shapes perception. Platforms that stay up become easier to trust with deeper integrations and higher volumes. Over time, that trust compounds and turns stability into a real advantage, even if it is rarely visible from the outside.

To conclude

The always-on economy creates real opportunity for fintechs, but it also raises expectations that many platforms were not originally built to meet.

The question is whether your system has the resilience to operate as infrastructure day after day. If you are a fintech and want to build with reliability in mind, get in touch .

Designing for resilience early makes it far easier to scale without introducing fragility later on.

The post The Always-On Economy: Fintech as Critical Infrastructure appeared first on Erlang Solutions .