Notika for...
FAQ
Get answers to frequently asked questions about Notika.
Notika is an automation tool that lets you set up transactional notification workflows without writing any code.
Unlike other notification services that require you to integrate their API into your application codebase, Notika connects directly to your database. This means anyone on your team, regardless of their technical expertise, can build and maintain notification workflows using a visual interface.
Transactional notifications are messages sent to users in response to specific actions or events in your application.
Examples include: welcome emails, reminders, order confirmations, weekly reports, payment receipts, and user activity digests.
Notika works by monitoring changes in your database and triggering notification workflows based on those changes:
- Connection: You connect Notika to your data source.
- Configuration: You build your notification workflows, specifying the trigger conditions based on changes in your database.
- Event Capture: After publishing a workflow, Notika monitors the relevant table for changes.
- Execution: When that change occurs, Notika picks up the event within seconds. Your defined notification workflow is then executed automatically on Notika’s infrastructure.
This entire process happens without requiring any code changes to your application.
When a key action happens in your application, it’s represented as some change in your database.
By connecting to your database, Notika lets you hook into those events and execute your notification workflows in real-time.
No, Notika is designed to have negligible impact on your database.
Only tables that trigger published workflows in Notika will have database triggers installed on them. These triggers run AFTER the relevant database operation in a non-blocking fashion.
Performance overhead is minimal as these triggers only log rows to a separate schema and do not perform any other operations.
No. Notika is designed for reliability.
Even if your database is temporarily unavailable or Notika experiences an outage, events will continue to be logged in the Notika-managed schema. When systems come back online, all unprocessed events will be picked up and executed in order.
To ensure robustness around transient errors (for instance, if your database is unavailable due to network connectivity issues), Notika automatically retries failed workflow steps with exponential backoff.
If a workflow fails after exhausting all retries, it will be marked as failed and you will be notified.
You can also configure custom error handling for specific workflows.
If your database is fully unresponsive, alongside the rest of your application, your workflows will pause until connectivity is restored.
When your database comes back online, Notika will process all accumulated events in the correct order. No notifications will be lost during the downtime.
Your database should be the source of truth for your application state. If you find yourself needing to track events outside the database, consider extending your data model to capture these state changes.
There are several strategies to ensure that your Notika workflows stay intact as you make changes to your database schema.
You can read more here.
At Notika, we take security seriously. Notika implements multiple layers of security to protect your data:
- All database connections use encrypted TLS
- Database access is limited to only the tables and operations needed
- All sensitive data is encrypted both in transit and at rest
- Regular security audits and penetration testing
See here for more details.
Was this page helpful?