1Run the Spice Runtime in a separate container or process on the same machine as the main application. For example, in Kubernetes as a [Sidecar Container](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/). This approach minimizes communication overhead as requests to the Spice Runtime are transported over local loopback.
2
3<img
4  width='740'
5  alt='sidecar'
6  src='https://github.com/user-attachments/assets/716f7c23-1939-4947-85f5-b0ee2bbd63fc'
7/>
8
9**Benefits**
10
11- Low-latency communication between the application and the Spice Runtime.
12- Simplified lifecycle management (same pod).
13- Isolated environment without needing a separate microservice.
14- Helps ensure resiliency and redundancy by replicating data across sidecars.
15
16**Considerations**
17
18- Each application pod includes a copy of the Spice Runtime, increasing resource usage.
19- Updating the Spice Runtime independently requires updating each pod.
20- Accelerated data is replicated to each sidecar, adding resiliency and redundancy but increasing resource usage and requests to data sources.
21- May increase overall cost due to resource duplication.
22
23**Use This Approach When**
24
25- Fast, low-latency interactions between the application and the Spice Runtime are needed (e.g., real-time decision-making).
26- Scaling needs are small or moderate, making duplication of the Spice Runtime in each pod acceptable.
27- Keeping the architecture simple without additional services or load balancers is preferred.
28- Performance and latency are prioritized over cost and complexity.
29
30**Example Use Case**
31A real-time trading bot or a data-intensive application that relies on immediate feedback, where minimal latency is critical. Both containers in the same pod ensure very fast data exchange.
32

1Run the Spice Runtime in a separate container or process on the same machine as the main application. For example, in Kubernetes as a [Sidecar Container](https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/). This approach minimizes communication overhead as requests to the Spice Runtime are transported over local loopback.
2
3<img
4  width='740'
5  alt='sidecar'
6  src='https://github.com/user-attachments/assets/716f7c23-1939-4947-85f5-b0ee2bbd63fc'
7/>
8
9**Benefits**
10
11- Low-latency communication between the application and the Spice Runtime.
12- Simplified lifecycle management (same pod).
13- Isolated environment without needing a separate microservice.
14- Helps ensure resiliency and redundancy by replicating data across sidecars.
15
16**Considerations**
17
18- Each application pod includes a copy of the Spice Runtime, increasing resource usage.
19- Updating the Spice Runtime independently requires updating each pod.
20- Accelerated data is replicated to each sidecar, adding resiliency and redundancy but increasing resource usage and requests to data sources.
21- May increase overall cost due to resource duplication.
22
23**Use This Approach When**
24
25- Fast, low-latency interactions between the application and the Spice Runtime are needed (e.g., real-time decision-making).
26- Scaling needs are small or moderate, making duplication of the Spice Runtime in each pod acceptable.
27- Keeping the architecture simple without additional services or load balancers is preferred.
28- Performance and latency are prioritized over cost and complexity.
29
30**Example Use Case**
31A real-time trading bot or a data-intensive application that relies on immediate feedback, where minimal latency is critical. Both containers in the same pod ensure very fast data exchange.
32