Solving Latency at Scale: How Atlassian Optimized Microservices with Sidecars pattern
The Problem: Latency Spikes in a Critical Service
Atlassian’s TCS (Transaction Coordination Service) is a high-performance backbone that handles millions of requests daily with a tight 5-6ms latency target and 99.99%+ availability. It ensures seamless communication between microservices—until something goes wrong.
One team at Atlassian started experiencing high latency and failure rates, while others had no issues. After investigation, the root cause was clear:
❌ Their client code made sequential requests to TCS instead of parallel ones, causing bottlenecks.
❌ This inefficiency slowed response times and led to request failures.
Simply asking teams to rewrite their client code wasn’t scalable. Atlassian needed a centralized solution that enforced best practices without manual intervention.
The Sidecar Pattern: A Scalable Fix
The sidecar pattern is a microservices architectural approach where a separate process, or "sidecar", is deployed alongside an application to handle common concerns like logging, security, and in this case, communication with TCS.
Rather than each microservice making direct HTTP calls to TCS, they communicate with the sidecar, which then manages the interaction. This ensures that all teams follow the same optimized best practices.
How Atlassian Implemented the Sidecar Pattern
Atlassian introduced a sidecar proxy between their microservices and TCS, creating a structured and efficient communication pipeline. Here’s how it worked:
✅ Local Communication – Instead of making direct network calls to TCS, services talk to the sidecar over local HTTP. This reduces network overhead and speeds up processing.
✅ Best Practices Enforcement – The sidecar automatically handles parallel requests, retries, and optimizations, eliminating performance bottlenecks caused by inefficient client code.
✅ Language-Agnostic Solution – Unlike a traditional library that must be implemented separately in each language, a sidecar can work with any programming language, making it easy to integrate across diverse tech stacks.
The Results: A 70% Reduction in Latency
The impact of the sidecar implementation was immediate and game-changing:
🚀 Latency Dropped by 70% – The teams struggling with high response times saw drastic performance improvements.
📉 Lower Request Volume – The sidecar reduced the overall number of calls sent to TCS by optimizing communication.
⚡ Consistent Performance – Even teams already following best practices saw enhanced efficiency, as the sidecar streamlined interactions for everyone.
Why the Sidecar Pattern Works
Atlassian’s success with the sidecar pattern highlights several key advantages:
🔹 Ensures Best Practices – Every service interacts with TCS optimally without requiring manual enforcement.
🔹 Works Across Tech Stacks – Unlike a library-based approach, a sidecar is language-independent.
🔹 Reduces Latency & Failures – Efficient request handling minimizes delays and improves system stability.
🔹 Scales Horizontally – Instead of solving performance issues team by team, the sidecar provides a single solutionthat benefits the entire organization.
When Should You Use the Sidecar Pattern?
The sidecar approach isn’t a one-size-fits-all solution, but it’s highly effective in these cases:
✔ Handling Cross-Cutting Concerns – Logging, monitoring, security, and rate limiting can all be offloaded to a sidecar.
✔ Optimizing Communication with Critical Services – If performance relies on a consistent interaction pattern, a sidecar can enforce best practices.
✔ Bridging Legacy and Modern Systems – A sidecar can act as a translator, allowing legacy applications to integrate with modern microservices seamlessly.
Lessons from Atlassian’s Implementation
1️⃣ Think Beyond Individual Fixes – Instead of patching one team’s problem, Atlassian built a scalable, organization-wide solution.
2️⃣ Centralize Communication Logic – By standardizing interactions, they eliminated inconsistencies and reduced failures.
3️⃣ Measure, Iterate, and Improve – Performance monitoring was key to identifying bottlenecks and proving the impact of the sidecar.
Final Thoughts: Should You Use the Sidecar Pattern?
Atlassian’s experience shows that solving inefficiencies at scale requires more than just fixing bad code—it requires architectural innovation.
If your team is facing latency issues, inconsistent performance, or struggling with best practice enforcement, a sidecar might be the answer. It’s a powerful tool that optimizes microservices communication, ensures best practices, and improves system-wide efficiency.
💡 Have you used the sidecar pattern in your architecture? Or are you considering implementing it? Drop your thoughts in the comments! 🚀