Skip to content

0058: Targeted Api Horizon Service

STATUS

Accepted Declined


## CONTEXT

The publisher integrations team wants to monitor `targeted-api` key queue metrics
such as job throughput, runtime, and job failures, through the implementation of
a Laravel [Horizon](https://laravel.com/docs/11.x/horizon) dashboard, improving the system's reliability and debugging processes.

### Considered options

* Serve Horizon dashboard as a standalone service
* Serve Horizon dashboard as a dependency from the `targeted-api` project

### Option 1: Serve Horizon dashboard as a standalone service

#### Description

Laravel Horizon could be deployed as an AWS ECS standalone service decoupled from the `targeted-api` project. That means while the dashboard is connected to the same Redis instance as the application, you can _"remotely"_ monitorize queue behavior.
It can be protected through a login authentication or IP whitelisting.

#### Diagram

```mermaid
sequenceDiagram
  Targeted Api->>Redis: Delegates queue handling<br/>
  Laravel Horizon->>Redis: Reads queue data from redis instance
  Laravel Horizon->>Laravel Horizon: Dogfoods dashboard with redis retrieved data

Pros

  • Decouples monitoring from the targeted-api monolith.
  • Horizon and his related dependencies could be updated without affecting the targeted-api service.
  • Reduces targeted-api code complexity since all UI code could be removed from the project
  • Reduces targeted-api authentication complexity since the standalone service will manage its own authentication system
  • Let us enforce targeted-api responses, into JSON, reducing security breach risk

Cons

  • Adds complexity to our architecture, since we'll need to manage two separate services
  • We'll need to configure and maintain two separate services, which can increase the time and effort required for maintenance tasks (updating dependencies, configurations, etc.)
  • There's not enough documentation; despite it's easy to setup, we could struggle to find fixes for different issues

Option 2: Serve Horizon dashboard as a dependency from the targeted-api project

Laravel Horizon is usually used by adding the dashboard as a project dependency, which means that the application monolith would contain the package, and monitoring would be locally made through the targeted-api. It can be protected through a login authentication or IP whitelisting.

Diagram

sequenceDiagram Targeted Api->>Redis: Delegates queue handling<br/> Redis->>Targeted Api: Reads queue data from redis instance Targeted Api->>Targeted Api: Dogfoods dashboard with redis retrieved data

Pros

  • Easier setup
  • Reduce architecture complexity, since we'll need to manage a single service
  • This kind of setup is widely documented, which means we'll usually find fixes for different issues
  • Maintaining a single service will reduce the time and effort required for different maintenance tasks (updating dependencies, configurations, etc.)

Cons

  • Increases targeted-api code complexity since the project would contain the API and dashboard UI
  • Increases targeted-api code complexity since we'll have to manage both API and dashboard authentication inside the same project
  • Horizon and its related dependencies updates could affect the targeted-api service
  • We'll need to allow UI responses, which could increase security breach risk

FEEDBACK/QUESTIONS/CONCERNS

Why using AWS ECS for Horizon service?

  • Automated Updates: AWS ECS allows us to configure automatic updates for the horizon container, which means we can keep the service up-to-date without manual intervention
  • Automatic restarts: AWS ECS can automatically restart the container if it fail or stop unexpectedly
  • Integration with CI/CD tools: AWS ECS integrates easily with Github Actions allowing us to automate the delivery pipeline
  • Isolation: Allows us to deploy horizon within the same VPC as the redis instance.
  • Cost-Effectiveness: Optimizes resource utilization compared to always-on EC2 instances.

Why not AWS EC2?

  • A single EC2 instance would require ongoing maintenance, including applying security patches, managing updates, and scaling resources manually. This adds operational overhead that can be avoided with ECS.
  • EC2 could become a bottleneck and represents a single point of failure, making it a less scalable solution.

DECISION

CONSEQUENCES

Risks

NOTES

References

Original Author

Daniel Ballesteros

Approval date

Approved by

Appendix

Appendix A: ECS Task Definition for Horizon Service

  • Container Configuration:

  • Environment variables set for Redis connection (host, port, credentials).

  • Networking configured to access Redis instance within the VPC.