Omni Base
From fragmented application backends to a unified platform for 20+ applications.
Role
System Design & Backend Engineering
Duration
3–6 months
Stack
Golang · MariaDB · Redis · Firebase
Omni Base was a backend platform built for DOTIX to support a growing portfolio of applications.
The problem was not that the existing applications were technically incapable of handling their workloads. The problem was that every new application repeated much of the same engineering and operational work.
Authentication had to be implemented again. Configuration had to be managed again. Databases and infrastructure had to be provisioned again. Application checks, payout logic, deployment and security controls were handled separately.
That model was manageable when there were only a few applications. With more than 20 applications in operation and new products being experimented with regularly, it became an operational bottleneck.
The purpose of Omni Base was to move the shared backend responsibilities into one platform.
The result was a system where an application could connect to an existing backend instead of bringing another complete backend stack with it.
The most visible outcome was deployment time. What previously took roughly 2--3 days could be reduced to approximately 12 minutes for a new application.
The more important outcome, however, was architectural: the team stopped treating every application as a completely independent backend system.
01. The Problem
DOTIX was operating a growing fleet of more than 20 applications.
Historically, applications were built using different combinations of:
- Self-hosted PHP backends
- MySQL
- Firebase
- Shared hosting
- Virtual machines
- Application-specific APIs and configuration
This was a reasonable way to get individual products running quickly. It became difficult to operate consistently as the application portfolio grew.
A new application often required repeating the same infrastructure work:
New application
|
+-- Backend
+-- Database
+-- Authentication
+-- Firebase
+-- Configuration
+-- APIs
+-- Security
+-- Deployment
+-- Monitoring
The individual pieces were not particularly unusual. The problem was repetition.
If ten applications need broadly similar capabilities, maintaining ten separate implementations means ten places where a bug can exist, ten places where a security rule can diverge, and ten deployments that may need to be coordinated.
This also created a growing operational dependency on the people who knew how each application had been configured.
The deployment problem
Launching a new application could take 2--3 days to get fully deployed and operational.
The work was not necessarily two or three days of continuous coding. A large part of the time was spent on provisioning, configuration, integration, testing and resolving environment-specific issues.
The pattern looked roughly like this:
New application
|
v
Provision hosting / VM
|
v
Configure backend
|
v
Configure database
|
v
Configure Firebase
|
v
Configure APIs
|
v
Configure security
|
v
Deploy
|
v
Test
|
v
Fix configuration issues
|
v
Application ready
This became increasingly expensive as the number of applications increased.
The engineering question was therefore not:
How do we make one application better?
It was:
How do we make the next application cheaper and easier to build?
02. The Payout Problem
Deployment speed was important, but payouts were the more serious architectural concern.
Most applications included some form of payout functionality.
Previously, payout-related logic was distributed across individual application backends. This meant that critical financial operations depended on application-specific implementations.
That created several risks.
A faulty implementation could produce an incorrect payout. A manipulated request could potentially reach payout-related logic without the same controls that another application used. Fixes also had to be applied to individual systems.
The problem was not only security in the narrow sense. It was control.
A payout is a business-critical operation. It should not be implemented differently in every application unless there is a very good reason to do so.
The architectural direction became clear:
Application
|
| payout request
v
Omni Base
|
+-- Validate
+-- Apply business rules
+-- Perform security checks
+-- Process payout
+-- Record operation
The application could request a payout, but the critical logic would live in a backend controlled centrally.
This gave the team one place to improve validation and security controls instead of maintaining the same sensitive logic across many applications.
03. The Goal
The goal was not to create another shared backend simply for the sake of consolidation.
The goal was to make application development and operations more predictable.
The desired workflow was:
New application
|
v
Connect to Omni Base
|
v
Configure application
|
v
Deploy
|
v
Ready
The platform would provide capabilities that were common across applications.
Applications would focus more on their own product-specific behavior instead of rebuilding infrastructure and backend functionality that already existed elsewhere.
The core idea was simple:
Build the common backend once, then let applications use it.
04. Architecture
Omni Base was built around a Go backend with MariaDB, Redis and Firebase.
+----------------------+
| Omni Base |
| Go Backend |
+----------+-----------+
|
+---------------------+---------------------+
| | |
MariaDB Redis Firebase
| | |
+---------------------+---------------------+
|
+-----------------+------------------+
| | |
App 01 App 02 App 20+
The important architectural change was not the choice of individual technologies.
The important change was where shared responsibilities lived.
Instead of:
App A -> Backend A -> Database A
App B -> Backend B -> Database B
App C -> Backend C -> Database C
the system moved toward:
App A \
App B \
App C ---> Omni Base ---> Shared infrastructure
App D /
App 20 /
This allowed the platform to own functionality that had previously been repeated across applications.
05. Why Go
Go was selected for the central backend.
The main requirement was a backend that could serve multiple applications while remaining straightforward to deploy and operate.
Go was a good fit for this role because the service needed to be:
- Long-running
- Efficient under concurrent requests
- Simple to deploy
- Easy to package as a single application
- Suitable for API-heavy workloads
- Straightforward to maintain
The value here was operational simplicity as much as raw performance.
A backend that can be built into a single executable and deployed consistently is useful when the same service becomes the foundation for many applications.
The platform did not need a complicated technology stack to solve the problem. It needed a predictable one.
06. Data and Infrastructure
Omni Base used different infrastructure components for different responsibilities.
MariaDB
MariaDB provided the persistent relational data layer.
Relational storage was appropriate for data where consistency and structured relationships mattered.
The database became a shared source of application and operational data rather than each application maintaining completely separate backend state.
Redis
Redis was used for fast-access and transient data needs.
A shared backend often needs operations that should not require a database query for every request. Redis provided a suitable layer for this type of workload.
It also gave the platform a place to introduce caching and other low-latency operations where needed.
Firebase
Firebase remained part of the architecture where its services were useful to the applications.
The goal of Omni Base was not to replace every existing technology.
It was to put a consistent backend layer around the application ecosystem and centralize the responsibilities that needed central control.
This distinction was important. A platform does not become better simply by replacing technologies. It becomes better when responsibilities are placed in the right layer.
07. Extracting Common Functionality
The next architectural step was identifying functionality that was repeated across applications.
The common capabilities included:
- Signup
- Authentication
- Profile operations
- Application checks
- Configuration
- Payouts
- Analytics
- Shared APIs
- Monitoring
These capabilities were moved toward the platform instead of being rebuilt independently.
Conceptually:
Omni Base
|
+--------------+--------------+
| | |
Identity Profiles Config
| | |
Payouts Checks Analytics
| | |
+--------------+--------------+
|
Apps
This separation made the application layer smaller.
An application did not need to own every piece of backend infrastructure just because it needed the capability.
It could consume the platform capability through the backend API.
08. Authentication and Profiles
Authentication was one of the clearest examples of functionality that should not be repeatedly implemented.
Instead of each application maintaining its own authentication flow, Omni Base provided a shared backend capability.
The same principle applied to profile operations.
This provided two practical advantages.
First, new applications could integrate existing functionality instead of rebuilding it.
Second, changes to shared behavior could be made at the platform level.
That reduced the chance that one application would slowly diverge from the behavior of the others.
09. Application Checks
Applications also needed checks to determine whether requests and application activity were valid.
Previously, these checks could be implemented independently.
Moving common checks into Omni Base created a central place for enforcing shared rules.
This mattered because an application ecosystem is difficult to manage when every application makes slightly different assumptions about what is valid.
Centralization did not mean every application had to behave identically.
It meant that rules that genuinely belonged to the platform could be implemented once.
10. Centralized Configuration
One of the practical benefits of the platform was centralized configuration.
Instead of embedding or separately managing every application setting, Omni Base became a central point for application configuration.
Conceptually:
Omni Base
|
+--------------+--------------+
| | |
App 01 App 02 App 20
| | |
Config Config Config
Configuration could be associated with individual applications and application versions.
This made it possible to change application behavior without treating every configuration change as a completely separate backend deployment.
It also created a clearer operational model:
Platform
|
+-- Application identity
+-- Application version
+-- Configuration
+-- Runtime behavior
As the application portfolio grew, this became increasingly useful.
11. Real-Time Synchronization
Centralized configuration becomes much more useful when applications can receive changes without requiring manual changes in every backend.
Omni Base therefore included real-time synchronization as part of the platform's operational model.
The important idea was that configuration became platform data rather than application-specific code.
That distinction reduced the amount of work required for operational changes.
Instead of:
Change requirement
|
+-- Modify App 01
+-- Modify App 02
+-- Modify App 03
+-- ...
+-- Deploy everything
the desired model became:
Change requirement
|
v
Update platform configuration
|
v
Applications receive the relevant state
This is a much easier model to operate when the number of applications continues to increase.
12. Centralizing Payouts
Payouts were one of the strongest reasons to centralize backend responsibilities.
The previous model distributed payout logic across applications.
The new model moved critical payout behavior into Omni Base.
Application
|
| Request payout
v
Omni Base
|
+-- Validate request
|
+-- Check application context
|
+-- Apply payout rules
|
+-- Perform security checks
|
+-- Process operation
|
+-- Record result
This had several advantages.
One place for validation
The same core validation logic could be applied consistently.
One place for security controls
Security-sensitive changes could be made centrally.
One place for operational fixes
If a problem was discovered in the payout flow, the platform could be updated without requiring independent implementations in every application.
Reduced application responsibility
Applications no longer needed to independently own the critical parts of payout processing.
This helped eliminate the recurring faulty-payout problem that had existed in the previous architecture.
The important lesson was that not every backend capability should be pushed into every application.
For sensitive operations, central control can be significantly easier to reason about and audit.
13. Deployment
Deployment was where the architectural change became easiest to measure.
Before Omni Base
A new application typically followed a process similar to:
New application
|
v
Provision infrastructure
|
v
Create backend environment
|
v
Configure database
|
v
Configure Firebase
|
v
Configure APIs
|
v
Configure security
|
v
Deploy
|
v
Test
|
v
Fix environment issues
Typical time:
2--3 days
Again, this included operational work rather than just writing application code.
After Omni Base
The process became:
New application
|
v
Connect to Omni Base
|
v
Configure application
|
v
Deploy
|
v
Ready
Typical time:
approximately 12 minutes
That is a reduction from roughly 48--72 hours to about 12 minutes.
In purely numerical terms, that is approximately a 240--360× reduction in deployment time.
The more important point is not the multiplier.
It is that deployment time stopped growing in proportion to the number of applications.
That is the property the platform was designed to achieve.
14. What Changed Operationally
The old model made each application partly responsible for its own infrastructure.
The new model separated responsibilities.
Before
Application
|
+-- Backend
+-- Database
+-- Authentication
+-- Configuration
+-- Payouts
+-- Infrastructure
+-- Security
After
Application
|
+-- Product-specific behavior
|
v
Omni Base
|
+-- Authentication
+-- Profiles
+-- Checks
+-- Configuration
+-- Payouts
+-- Analytics
+-- Shared APIs
+-- Monitoring
This was a shift from application-by-application infrastructure toward a shared platform.
The platform absorbed the repeated work.
15. Analytics
Analytics were also brought into the platform.
As applications became connected to a common backend, it became possible to build a more centralized view of activity.
The platform provided visibility into areas such as:
- Users
- Application activity
- Usage
- Requests
- Operational data
This was particularly useful because the alternative was to collect similar information from many independent application backends.
With a shared platform, analytics could be designed around the application fleet rather than around individual products.
This became more valuable as the number of applications and requests increased.
16. Scale
Omni Base eventually supported:
- 20+ applications
- 500+ active users at a time
- Millions of requests across multiple applications
These numbers are important because the platform was not built as an isolated internal prototype.
It became infrastructure used by a real application portfolio.
The scaling challenge was therefore broader than handling HTTP requests.
The system had to make it possible to operate many applications without multiplying operational effort at the same rate.
That distinction matters.
A backend can technically handle a high request count while still being difficult to operate.
Omni Base was intended to address both sides of the problem:
Technical scale
+
Operational scale
The second part became increasingly important as the number of applications grew.
17. Monitoring
Once multiple applications depend on one backend, monitoring becomes more important.
A failure in the shared platform can affect several applications at once.
Omni Base therefore included monitoring as part of the platform rather than treating it as an afterthought for each individual application.
The monitoring model considered signals such as:
- API health
- Server behavior
- Logs
- Application behavior
- Operational events
This gave the team a centralized place to inspect the health of the application ecosystem.
The architecture also created an important foundation for automated analysis.
18. AI-Assisted Self-Awareness
One of the later areas of development was an AI-assisted monitoring capability.
The idea was to make the platform better at interpreting its own operational signals.
The concept looked like this:
Server / API
|
v
Monitoring
|
v
Logs + operational signals
|
v
AI analysis
|
v
Potential issue identified
|
v
Human intervention
The purpose was not to claim that the system could autonomously operate production infrastructure.
The useful part was the analysis step.
Production systems generate a large amount of information. Logs, health checks and API failures can be individually understandable while still being difficult to correlate.
AI could help interpret these signals and surface a possible problem faster.
This capability was an active area of development and experimentation.
That distinction matters: it was a direction the platform was being extended toward, not a claim that the system had become fully autonomous.
19. AI Site Builder
Omni Base was also part of a broader effort to reduce the time required to launch applications.
A new application did not only need a backend.
It also needed a basic public website, often including:
- Landing page
- Privacy policy
- Terms
- Other informational pages
Previously, producing these pages could take weeks depending on the application and requirements.
DOTIX began building an internal AI Site Builder to generate these pages in minutes.
The tool was still under active development, but the architectural direction was straightforward:
Application idea
|
+---- Backend
| |
| +---- Omni Base
|
+---- Infrastructure
| |
| +---- Standardized deployment
|
+---- Website
|
+---- AI Site Builder
This addressed another part of the application launch process.
Omni Base reduced backend and infrastructure setup.
The AI Site Builder reduced the work required to create the supporting web presence.
Together, they reduced the amount of repeated work required before an application could be tested in the real world.
20. Why the Platform Approach Worked
The key architectural decision was to identify which responsibilities belonged to an individual application and which belonged to the platform.
Not everything should be centralized.
Product-specific business logic should remain close to the application that owns it.
Shared capabilities should be implemented once when there is a clear reason for doing so.
The resulting boundary looked roughly like:
+---------------------------------------------+
| Application |
| |
| Product-specific logic |
| Product-specific UI |
| Product-specific workflows |
+----------------------+----------------------+
|
| API
v
+---------------------------------------------+
| Omni Base |
| |
| Authentication |
| Profiles |
| Checks |
| Configuration |
| Payouts |
| Analytics |
| Shared APIs |
| Monitoring |
+----------------------+----------------------+
|
v
+---------------------------------------------+
| MariaDB / Redis / Firebase |
+---------------------------------------------+
This separation made the platform useful without turning it into a replacement for the applications themselves.
21. The Trade-offs
Centralizing backend functionality also introduces trade-offs.
A shared platform creates a dependency.
If several applications depend on Omni Base, an outage or incompatible change in the platform can affect several applications at once.
That means platform reliability and backward compatibility become more important than they were when applications were completely independent.
There is also a risk of putting too much into the shared backend.
If every product-specific feature is moved into Omni Base, the platform can become difficult to change because every application becomes dependent on its behavior.
The design therefore needs a clear boundary:
- Shared functionality belongs in the platform.
- Product-specific functionality belongs in the application.
- Security-sensitive shared operations should have strong central controls.
- Platform APIs should evolve carefully because multiple applications depend on them.
These are important lessons from building a shared backend rather than simply extracting code into a common repository.
22. The Engineering Lessons
1. Repetition is an architectural signal
If the same infrastructure work happens for every application, the problem is no longer just developer productivity.
It can indicate that a capability belongs at a different architectural layer.
Omni Base was a response to that signal.
2. Centralization is most valuable for the right responsibilities
Authentication, shared configuration and payout controls benefited from centralization because they were common across applications.
The platform was not intended to contain every piece of application logic.
3. Security-sensitive operations should have clear ownership
Payouts demonstrated why this matters.
When a sensitive operation is implemented independently in many systems, enforcing consistent rules becomes harder.
Centralizing the critical path made ownership clearer.
4. Deployment time is an engineering metric
A deployment taking two days is not only an operations problem.
It directly limits how quickly a team can experiment.
Reducing deployment to roughly 12 minutes changed the economics of trying a new application.
5. Scaling includes operations
Supporting more requests is only one part of scaling.
If adding application number 21 requires the same manual setup as application number 1, the architecture has not scaled operationally.
A useful platform should reduce the marginal cost of adding another application.
6. Standardization creates leverage
Once applications use the same backend capabilities, improvements to those capabilities can benefit multiple products.
A security improvement, configuration mechanism or monitoring feature no longer needs to be independently implemented everywhere.
23. Results
The measurable and operational outcomes were significant.
Area Before With Omni Base
Application count Growing independently 20+ applications on a shared platform
New application 2--3 days Approximately 12 deployment minutes
Authentication Application-specific Centralized
Configuration Distributed Centralized
Payout logic Distributed across Centralized critical applications flow
Analytics Scattered across Shared platform view applications
Monitoring Application/infrastructure Centralized platform dependent capability
Active users Distributed across systems 500+ active users at a time
Requests Distributed Millions across multiple applications
Supporting website Could take weeks AI Site Builder creation targeted minutes
The most important outcome was not any individual technology.
It was the change in the cost of launching and operating another application.
24. Business Impact
Omni Base changed the way DOTIX could operate its application portfolio.
Before the platform, adding an application also meant adding another set of infrastructure and backend responsibilities.
After the platform, the next application could reuse existing capabilities.
That affected several parts of the business:
Faster experimentation
A new application could move from idea to deployed backend much faster.
Lower operational overhead
Repeated infrastructure and backend setup was reduced.
Better control over sensitive operations
Payout functionality had a centrally controlled backend path.
More consistent application behavior
Common capabilities were implemented at the platform level.
Better visibility
Centralized analytics and monitoring provided a broader view of the application fleet.
Higher product velocity
Engineering effort could be spent more heavily on product-specific work instead of repeating infrastructure setup.
Revenue impact
The reduced cost and time required to launch applications contributed to DOTIX being able to operate and experiment with more products, which in turn contributed to increased revenue.
The central business idea was simple:
Infrastructure stopped being a bottleneck for launching applications and became an enabler for launching more of them.
25. What I Would Keep in Mind When Building This Again
If I were designing the platform again, I would treat the shared API contract as one of the most important pieces of the system.
Once 20+ applications depend on a backend, changing that backend is no longer equivalent to changing one application's internal code.
I would therefore pay particular attention to:
- API versioning
- Backward compatibility
- Authentication boundaries
- Authorization
- Auditability of sensitive operations
- Configuration ownership
- Failure isolation
- Rate limiting
- Observability
- Database migrations
- Rollback strategy
- Contract testing
- Dependency management between applications and the platform
These concerns become more important as the platform grows.
The original problem was removing duplicated infrastructure work. The next problem becomes making the shared infrastructure safe to evolve.
That is the natural progression of a platform.
26. What This Project Taught Me About System Design
The most important lesson from Omni Base was that system design is often about deciding where responsibility should live.
It is easy to focus on the technology:
Go
MariaDB
Redis
Firebase
Those technologies matter, but they were not the core architectural decision.
The more important decisions were:
What belongs to the application?
What belongs to the platform?
What should be centralized?
What should remain independent?
Which operations require stronger controls?
How can another application reuse the same infrastructure?
How can the platform evolve without breaking its consumers?
The deployment improvement was a consequence of those decisions.
The security improvements were a consequence of those decisions.
The centralized analytics and configuration were consequences of those decisions.
The ability to support more applications without proportionally increasing infrastructure work was also a consequence of those decisions.
That is the part of the project I consider most valuable from a system design perspective.
27. Final Takeaway
Omni Base started with a practical problem:
DOTIX had too many applications being operated as separate backend systems.
The solution was to build a shared platform around the functionality those applications had in common.
The architecture moved from:
Many applications
+
Many backends
+
Repeated infrastructure
+
Repeated security-sensitive logic
toward:
Many applications
|
v
Omni Base
|
+-- Shared APIs
+-- Authentication
+-- Profiles
+-- Checks
+-- Configuration
+-- Payouts
+-- Analytics
+-- Monitoring
|
v
Shared infrastructure
The clearest result was the reduction in deployment time:
2--3 days → approximately 12 minutes.
But the larger result was architectural.
The team could add another application without starting the backend infrastructure process from zero.
That is what made Omni Base valuable.
It was not simply a new backend.
It was a change in how the company built and operated software.