What is Not Included in a Service Proxy?

In modern distributed systems, particularly when utilizing Service Mesh technologies like Istio, Linkerd, or Envoy, the term "service proxy" refers to the sidecar or gateway proxy that handles network traffic. As a senior web scraping and proxy architect, I often see engineers misunderstanding the boundaries of this component.

The fundamental design philosophy of a service proxy (specifically an "Extensible Service Proxy" or ESP) is to be a transparent, dumb pipe with smart control features. It focuses on the network layer, leaving the application layer to the service itself.

Below is a deep dive into what is explicitly excluded from a service proxy to ensure your architecture remains clean, secure, and performant in 2025.

---

1. Core Business Logic Implementation

The most critical exclusion is the actual "reason" the service exists.

A service proxy does not know *what* your application does; it only knows *where* to send the traffic. If you run a Python-based scraping service, the proxy handles the incoming HTTP request, but the code that parses the HTML, extracts the data, and saves it to S3 is not in the proxy.

Real-World Example:

Consider a payment microservice.

• Included in Proxy: TLS termination, basic auth validation, routing traffic to /v1/charge.
• NOT Included in Proxy: The actual calculation of interest, the communication with the banking ledger, or the logic that checks if a user has sufficient funds.

If you try to embed business logic into a proxy (often done via complex WebAssembly filters or Lua scripts in Nginx), you violate the Single Responsibility Principle. This makes the system harder to debug. In 2025, we keep proxies lightweight (usually Envoy or Rust-based) to ensure microsecond-latency, reserving CPU cycles for the business logic running in the main container.

---

2. Stateful Data Persistence

While a service proxy can maintain a *temporary* state during a connection (e.g., tracking active requests in a circuit breaker), it is stateless regarding the business data.

What is Excluded:

• Databases: The proxy does not write to your Postgres or MongoDB.
• User Sessions: While it can *route* based on a session cookie, it does not *store* the session data itself (unless specifically configured as a session-aware load balancer, but even then, this is transient).
• Long-term Caching: A proxy does not serve as your Content Delivery Network (CDN) or Redis cache.

Why This Matters for Scalability:

Because proxies exclude state, they can be scaled horizontally (add more pods) instantly without worrying about data migration. If your proxy held state (e.g., "User A is connected to Proxy B"), losing that proxy instance would result in data loss. In 2025 architectures, we rely on external state stores (Redis, DynamoDB) accessed *by* the service, keeping the proxy stateless.

---

3. Complex Data Transformation & Marshalling

One of the common pitfalls in API Gateway implementations is offloading too much data processing to the proxy.

The Boundary:

A service proxy is optimized for pass-through.

• Included: Header manipulation (adding X-Request-ID), simple protocol translation (HTTP1.1 to HTTP/2), or basic JSON validation.
• NOT Included: Large XML to JSON conversion, massive payload restructuring, or combining responses from 10 different microservices into one (Aggregation).

The "Service Proxy" vs "Backend for Frontend" (BFF)

Aggregation logic (combining a User Profile, an Order History, and a Recommendation into a single JSON response for a mobile app) is strictly not included in a standard service proxy. That belongs in a BFF or the application layer. If you force this logic into the proxy (e.g., using complex VCL or Lua), you introduce latency that blocks the network thread, degrading performance for all other services on the mesh.

---

4. Authentication *Data* vs Validation

This is a nuanced exclusion. A service proxy almost always handles AuthN (Authentication) validation, but it does not handle the Identity Management.

What is Included:

• Checking a JWT signature.
• Verifying an API Key exists in a deny/allow list.
• Enforcing mTLS (mutual TLS) between services.

What is NOT Included:

• The User Database: The proxy does not query the "users" table to check a password.
• Identity Provisioning: The proxy does not create users, reset passwords, or handle MFA enrollment flows.
• Dynamic Authorization (Opa): While advanced setups can pull policies, the complex evaluation of "Does User A have permission to edit Document B in Context C?" is often too heavy for a simple Envoy proxy and is offloaded to the service or a dedicated Policy Decision Point.

---

Technical Comparison: Proxy vs. Service

To clarify the boundaries, here is a comparison of responsibilities in a modern 2025 Stack.

| Feature | Included in Service Proxy? | Included in Application Service? | | :--- | :---: | :---: | | Transport Security (mTLS) | YES | NO | | Service Discovery (Routing) | YES | NO | | Retries / Timeouts | YES | NO | | Rate Limiting (Local) | YES | NO | | Request Validation (XSD/JSON Schema) | Maybe (Basic) | YES (Complex) | | Database Connections | NO | YES | | Business Logic (If/Else) | NO | YES | | HTML Parsing / Scraping Logic | NO | YES | | Persistent Caching | NO | YES (via Redis) |

---

Python Example: The Boundary in Code

Let's look at a typical setup using Envoy as a service proxy for a Flask web scraping service.

The Application Service (What is NOT in the Proxy)

app.py
This code runs in the Application Container.
It contains BUSINESS LOGIC excluded from the proxy.
from flask import Flask, jsonify import requests
app = Flask(__name__)
@app.route('/scrape/') def scrape_site(target_url): # Logic: Fetching, Parsing, and transforming data. # The proxy knows nothing about 'BeautifulSoup' or HTTP requests to the target.
try: response = requests.get(target_url, headers={'User-Agent': 'ProxyFAQs-Bot'})
# Business Logic: Extract price price = parse_price(response.text)
return jsonify({"url": target_url, "price": price})
except Exception as e: return jsonify({"error": str(e)}), 500
if __name__ == '__main__': app.run(port=8080) 

The Service Proxy (The Config)

envoy.yaml
This configures the Proxy Sidecar.
It contains NETWORKING logic excluded from the app.
static_resources: listeners: - name: listener_0 address: socket_address: address: 0.0.0.0 port_value: 10000 filter_chains: - filters: - name: envoy.filters.network.http_connection_manager config: stat_prefix: ingress_http route_config: name: local_route virtual_hosts: - name: backend domains: ["*"] routes: - match: { prefix: "/" } route: { cluster: service_a } http_filters: - name: envoy.filters.http.router clusters: - name: service_a connect_timeout: 0.25s type: STRICT_DNS lb_policy: ROUND_ROBIN http2_protocol_options: {} load_assignment: cluster_name: service_a endpoints: - lb_endpoints: - endpoint: address: socket_address: address: 127.0.0.1 port_value: 8080 # Forwarding to Python App 

Analysis: In the example above, the Envoy proxy (configured in YAML) handles the network ingress, routing, and connection pooling. It does not contain the requests library logic or the price parsing function. If the Python code crashes, the proxy returns a 503. If the Proxy crashes, the Python app keeps running but is unreachable.

---

Extensible Service Proxy (ESP) Nuances

When discussing Extensible Service Proxies (often associated with Google Cloud Endpoints or Envoy-based extensions), the line blurs slightly. ESPs allow you to add "extensions" or "filters."

However, even in 2025, the constraints remain: 1. Latency: Any code executed in the proxy must be extremely fast. Heavy regex or database queries are excluded. 2. Reliability: If your extension crashes the proxy, you lose network connectivity to the service. Therefore, critical logic is excluded from the proxy layer for safety reasons.

Conclusion

To summarize, a service proxy is a dedicated infrastructure component designed for reliability and speed. It explicitly excludes:

1. Application Code: The "brains" of your operation. 2. Stateful Storage: Database or file system persistence. 3. Complex Processing: Heavy data transformation or aggregation.

By keeping these exclusions clear, you ensure your Service Mesh remains a high-speed network layer, while your application services remain the robust, stateful engines of your business.