I use it to handle messages from the WhatsApp API. There is a product in my company that uses that API, and Temporal helps us debug and handle retries about the messages we receive, persisting the delivery of the message to the final client.

I like the inner retry system that it has, as a developer. The availability it provides to our products is great. When a micro service crash, Temporal handles the retry by itself. It helps a lot in our company and is by far the best thing Temporal has created.

I think people need to have some experience, at least with event-driven design. When someone tries to understand the signals, queries, and updates, it becomes a little challenging if they haven’t worked with webhooks or event sockets. But if someone already knows about event-driven designs, it’s pretty simple.

Sometimes it scales kind of badly, but it depends on the process of our products. If we have too many signals in a workflow, we might need 50 or 60 pods of the same worker. But this doesn’t happen with every worker; it just happens in some special use cases.

The scalability is great, but could be better.

We needed to change Temporal's database from Postgres to Cassandra to handle it more cheaply for our infrastructure. We do not use Temporal Cloud; we use Temporal Open Source. Cassandra DB was the best choice because it was cheaper. The problem with Postgres was the only problem we faced. But besides that, it has been great since the start.

I have been using it since January 2023. I’ve been using it every day since.

One time, we had a problem with the database. Our PostgreSQL queries from Temporal reached the maximum connections at the same time, and then Temporal’s cluster crashed. It was the only time, and it was a problem with our infrastructure. When we changed it to Cassandra, it never happened again.

I would rate the stability a nine out of ten.

It’s working fine in my current company. We have about three million workflows running at the same time. Sometimes it scales kind of badly, but it depends on the process of our products. If we have too many signals in a workflow, we might need 50 or 60 pods of the same worker. But this doesn’t happen with every worker; it just happens in some special use cases. In general, I think it’s great but could be better.

I would rate the scalability an eight out of ten.

I haven’t faced another challenge besides scalability. We drive around five million events in a small day.

I never needed the support, but sometimes I use the community to speak with them.

The initial setup is easy. I didn’t have any problems deploying it in production or on the devs’ local host. It was pretty great for the devs in general. I think it’s pretty great.

Our project was designed in Temporal. It started with Temporal, so we didn’t have any problems before.

We handle on-premises, and we participate in Temporal community.

There’s a return on investment and it’s worth the money.

Temporal OSS is expensive in infrastructure, but it brings back the reliability that companies need.

I would recommend it to other people. Try Temporal Cloud because on-premise is kind of expensive.

Overall, I would rate it a nine out of ten.

We use the product in our environment to manage a complex data pipeline for our highly data-intensive virtual operating system. Our system processes continuous data flows from instruments worldwide that collect stratospheric weather data. This data undergoes multiple conversions through several layers to reach an L2 format.

The platform has significantly improved our organization's handling of complex and long-running workflows. It has enhanced our distributed systems' resilience and fault tolerance, especially considering our extensive use of load balancers, API gateways, and complex server configurations. It ensures that if something goes wrong, it is handled in a way that minimizes harm.

The solution's most valuable features include its ability to simplify the management of complex workflows, improve system resilience and fault tolerance, and reduce the need for extensive boilerplate code.

One area for the product improvement is the learning curve. It can be challenging for new users, particularly those unfamiliar with the concept of workflow as code or data-centric applications. The complexity of managing the pipeline introduces some operational overhead, which requires more communication and coordination within the team.

I have been using Temporal for approximately nine months.

The solution is highly stable, particularly in maintaining resilience and fault tolerance across distributed systems.

I have had positive experiences with Temporal's support, particularly through their Slack workspace, where original developers are highly responsive and engaged in user support. They typically respond within a minute and remain involved until the issue is resolved.

Previously, we used tools like Airflow and DAXTER. We switched to Temporal because it offers superior fault tolerance and robust techniques for handling complex workflows.

The setup complexity is context-dependent. For our proprietary system, we integrated Temporal, which required managing multiple integration points, such as Docker servers, endpoints, distributed databases, and configuration management systems like NGINX or Caddy. While the installation was straightforward, the testing process was more complex due to using workflows as daemon processes.

The implementation was done in-house.

For those new to workflow orchestration tools, start with simpler tools like Airflow before transitioning to Temporal.

Temporal is better suited for users with a solid concept understanding and a well-developed intuition for complex systems.

It was chosen for its robust techniques in handling such complex workflows. We operate it on-premises using dedicated servers, and our customized scripts manage it.

I rate it a ten out of ten.