As distributed systems grow, one of the first things teams lose sight of is the lateral traffic flowing between services. North-south traffic typically becomes visible at load balancer, WAF, or reverse proxy layers; but east-west traffic often gets buried inside application logs, node metrics, and scattered trace records. Not every organization has the right timing or operational capacity to invest in a service mesh. In that case, the goal is to disciplinedly raise visibility before introducing a mesh.
Where does the problem actually start?
As microservices multiply, teams typically struggle to answer questions like these quickly:
- Which service talks to which port and over which protocol?
- Is a request’s latency coming from the network or the application layer?
- Which service chain is generating retry storms?
- Are there unexpected calls happening within the same segment?
When these questions go unanswered, the issue isn’t only operational. Security teams also have a hard time noticing unexpected lateral communication. The risk multiplies especially when ERP integrations, internal service networks, and hybrid connections share the same environment.
Four data sources for visibility without a mesh
A service mesh often provides an attractive framework for policy enforcement and telemetry generation. However, a significant portion of similar visibility can also be built from the following layers:
- L7 reverse proxy logs: Proxies like Envoy, NGINX, or HAProxy produce centralized access records.
- eBPF or flow telemetry: Connection-level activity and latency signals are captured at the kernel level.
- OpenTelemetry instrumentation: Application calls are processed as traces and metrics.
- Network flow data: VPC flow logs, firewall logs, or switch telemetry sources reveal the broader picture.
The aim here is not to pick one magic tool, but to bind these signals to a shared event model.
Where should you begin?
A practical starting point is making service call ownership a required field. Even if you can’t see every call, enrich every flow you do see with these common labels:
source.servicedestination.serviceenvironmentregionteamcriticality
Without these fields, the network data you collect may be technically rich but operationally weak.
How can the observation architecture be built?
A sustainable approach at enterprise scale typically follows this flow:
- A standard proxy layer is placed in front of critical services that ingress and egress.
- Connection and packet behavior is gathered at the node level by eBPF-based agents.
- Application teams emit traces for critical request chains.
- All signals are correlated within a shared observability platform.
A key advantage of this model is that you don’t have to transform the entire platform at once. You start with the most critical service clusters, then gradually shrink the dark zones.
Which metrics actually matter?
In east-west traffic observability, everyone looks at connection counts; but the truly valuable signals are these:
- Per-service P95 and P99 latency
- Error rate and percentage of reset connections
- New and unexpected service dependencies
- Retry intensity from a single client
- Traffic deviations by region or segment
These signals catch not only performance issues but also problems like bad releases, misresolved DNS, or misconfigured security policies early on.
What’s the security upside?
East-west traffic visibility delivers three clear advantages to security teams:
- Unexpected lateral movement behavior is recognized faster.
- Microsegmentation is built around real service dependencies, not theoretical ones.
- Legacy protocols without authentication on the internal network become more visible.
Old ERP services in particular, batch jobs that use file shares, and helper systems that talk via service accounts quickly stand out in this analysis.
When does a mesh actually become necessary?
When the number of services climbs, when separation of duties between teams deepens, and when policies like mTLS become mandatory, a service mesh starts producing serious value. But establishing the visibility layer earlier also makes the mesh transition safer. Because by then, you already know which flows are critical, which are unnecessary, and which are exceptions.
Conclusion
A service mesh is a powerful tool in distributed systems; but it is not the first or only option for visibility needs. When you combine east-west traffic with proxy logs, eBPF signals, trace data, and network flow records, performance, security, and architectural debt show up in the same picture. In enterprise platforms, the right approach is to first understand the traffic, then bring mandatory control layers online.