Elasticsearch: how to scale without overspending

Oct 7, 2025 | Camunda, NTConsult

Elasticsearch is a distributed search and analytics engine used to quickly retrieve and analyze large volumes of structured and unstructured data. In enterprise environments, it supports use cases like searching transaction histories in financial systems, tracking user activity logs in digital products, or monitoring process execution in automation platforms. Its ability to deliver near real-time insights makes it essential for companies that need operational visibility across high-volume, data-intensive workflows, such as banks, insurers, and telecom providers.

Its performance and scalability have made Elasticsearch a common component in modern enterprise stacks, particularly where large volumes of operational or transactional data need to be searched and analyzed in real time. However, when implemented without attention to indexing strategies, data retention, and query design, it can become a source of unnecessary cost and complexity, especially in cloud environments.

Without proper index strategy, query optimization, or storage tiering, cloud costs can spiral, sometimes doubling or tripling without warning. These issues are often hidden behind high ingestion rates, generic configurations, or inefficient BPM integrations. That’s where architecture makes all the difference. 

If your Elasticsearch bill keeps climbing or your stack feels sluggish under load, the problem may not be the tool, but how it’s being used. Keep reading to learn how strategic orchestration and architecture decisions can turn Elasticsearch from a cost center into a performance asset.

What is Elasticsearch and how does it work?

Elasticsearch is a distributed, RESTful search and analytics engine designed to handle both structured and unstructured data at scale. Unlike traditional relational databases, which are optimized for strict schema and transactional integrity, Elasticsearch is designed for speed, flexibility, and near real-time processing, making it ideal for scenarios where rapid search, filtering, and aggregation are needed.

In enterprise environments, Elasticsearch is commonly used for:

  • Full-text search, enabling fast retrieval across large volumes of documents or records.
  • Filtering and faceting, to support dashboards and complex queries.
  • Log data analysis, processing application or infrastructure logs in real time.
  • System monitoring, especially when combined with observability stacks like the Elastic Stack (ELK).

One of its core advantages is scalability. Elasticsearch distributes data across multiple nodes and shards, allowing for horizontal growth and high availability. Its architecture supports quick ingestion and querying, even as data volumes increase.

In process orchestration contexts, Elasticsearch often serves as the backbone for operational visibility. It powers monitoring tools like Operate and Tasklist, helping business and technical teams track the status of process instances, identify bottlenecks, and audit historical activity.

This flexibility, while powerful, also introduces complexity. Poorly designed indices, excessive data ingestion, and one-size-fits-all configurations can significantly impact performance and drive up cloud costs. To avoid these pitfalls, teams need to go beyond default settings and understand how Elasticsearch behaves under real operational loads, especially when supporting high-throughput, data-intensive applications.

The hidden cost of poor Elasticsearch implementation

While Elasticsearch is known for its scalability and speed, misconfigured deployments can result in hidden (and significant) operational costs. In many cloud environments, where pricing is based on compute, storage, and data transfer, even minor inefficiencies can compound quickly.

Uncontrolled data indexing, unfiltered ingestion, and default configurations often cause resource overuse. When all data is retained indefinitely, indexed uniformly, and stored without differentiation (hot/warm/cold tiers), cloud costs rise disproportionately, with no added business value.

In one real case, NTConsult identified a scenario where a large financial institution was incurring over $6/hour in infrastructure costs simply due to excessive Elasticsearch usage. The system was processing far more data than needed, storing it in high-cost storage classes, and applying flat configurations across all workloads.

These aren’t isolated issues. They’re symptoms of broader architectural misalignment, where orchestration layers generate more signals than the infrastructure is prepared to handle.

This is why we start every engagement with a full-stack audit. By analyzing ingestion patterns, index growth, and real-time query loads, we uncover hidden inefficiencies and propose architectural corrections that deliver measurable financial impact.

Common integration pitfalls: BPM and Elasticsearch

The root of many Elasticsearch inefficiencies lies not in the engine itself, but in how orchestration platforms integrate with it. When Business Process Management (BPM) tools aren’t configured with performance and cost in mind, they can flood Elasticsearch with redundant operations and unstructured data.

Key pitfalls include:

  • Event overload: high-frequency workflows generate logs and variable changes that are indexed automatically, often without prioritization.
  • Poor orchestration-query sync: Elasticsearch queries are triggered at fixed intervals, regardless of need, leading to unnecessary load.
  • Inefficient BPMN patterns: loops, polling mechanisms, and excessive variable propagation increase both process latency and data volume.
  • Legacy system bridges: bulk data pushes from external systems into Elasticsearch without filtering or normalization.

For sectors like finance and telecom, where process observability and SLA tracking are essential for operational continuity, these inefficiencies can create real bottlenecks in infrastructure costs and in user experience and operational risk.

In these scenarios, resolving performance and cost issues often requires rethinking how orchestration layers interact with Elasticsearch, from eliminating anti-patterns in process models to reducing unnecessary variable payloads and applying tiered indexing strategies.

By addressing these root causes, we transform Elasticsearch from a bottleneck into an enabler, fully aligned with your business and technical goals.

Real-world case: optimizing Elasticsearch and Camunda for cost, performance, and future readiness

A major financial institution engaged NTConsult to address growing concerns with its process orchestration platform based on Camunda 8 integrated with Elasticsearch. The environment, central to their digital operations, was facing increasing pressure due to architectural inefficiencies, cloud cost escalation, and limits on scalability.

NTConsult was brought in to conduct a comprehensive technical review of the full orchestration stack, aiming to restore performance, improve stability, and regain cost control. The engagement was structured in two strategic phases:

  • Project 1 focused on the Elasticsearch layer, with the goal of reducing index volume, improving storage efficiency, and lowering cloud expenses.
  • Project 2 targeted the job execution architecture, restructuring the process layer to improve modularity, scalability, and execution performance.

Together, these initiatives delivered a long-term foundation for operational maturity, greater resource efficiency, and readiness for future demands.

Project 1 — Elasticsearch optimization and cost control

The client’s Elasticsearch environment had grown inefficient due to generic configurations and uncontrolled data growth. Indexes from Camunda’s Operate and Tasklist components were not differentiated by usage patterns, resulting in excessive storage consumption and suboptimal performance.

NTConsult implemented a series of architectural corrections:

  • Custom shard/replica strategies per index.
  • Hot/warm tiered storage policies, with historical read-only data moved to warm nodes after 24 hours.
  • Automation of force merges and retention routines via Kubernetes CronJobs.
  • Elimination of BPMN anti-patterns, including polling loops and excessive variable propagation.
  • Expanded monitoring stack, integrating Grafana with tailored dashboards and alerts.

Results:

  • Data volume in Elasticsearch reduced from 1.33 TB to 287 GB.
  • Infrastructure costs decreased from $6.90/hour to $3.50/hour, with potential for $2.09/hour.
  • Ingestion and archiving became significantly faster and more stable.
  • Full visibility and Operate functionality were preserved, no loss of capability.

This phase demonstrated that with targeted adjustments, guided by process awareness, it is possible to drastically reduce resource consumption and cost without sacrificing system functionality or visibility.

Project 2 — Job worker architecture redesign for scalable execution

Originally, the platform used a single generic job worker to handle all process executions, which led to performance bottlenecks, complex logic, and heavy resource consumption. This monolithic setup made it difficult to isolate failures or scale specific integrations.

NTConsult restructured the execution model by:

  • Introducing multiple specialized workers, each handling specific tasks or system integrations (e.g., payments, inventory, logistics).
  • Applying development standards to improve modularity, fault tolerance, and performance.
  • Eliminating unnecessary BPMN loops and reducing the propagation of large variable sets.
  • Enabling selective scalability, so each worker could scale based on load and priority.

Results:

  • Improved throughput and more resilient process execution.
  • Reduced consumption of Camunda cluster resources.
  • Cleaner, more maintainable codebase with clearer separation of responsibilities.
  • A flexible foundation ready for future enhancements, including AI-driven agents and smart automation.

By modularizing the execution logic and aligning it with operational needs, NTConsult enabled the client’s automation platform to scale predictably and efficiently, laying the groundwork for sustained process evolution.

Takeaways from the combined optimization

By addressing both infrastructure and execution layers, NTConsult delivered a full-stack transformation that aligned cost, performance, and long-term scalability:

  • The platform is now optimized across cost, architecture, and execution logic.
  • Scalable both horizontally and vertically, depending on business demand.
  • Lower maintenance burden, with quicker support resolution.
  • A clear ROI path with quantifiable savings and performance gains.

This case illustrates the impact of addressing orchestration and infrastructure challenges together, moving from fragmented, high-maintenance automation to a scalable and resilient operational model supported by clear architectural decisions. That’s the kind of orchestration-first engineering NTConsult brings to complex enterprise environments.

Best practices to optimize Elasticsearch in your architecture

Efficient Elasticsearch usage starts with one core principle: index only what delivers value.

In orchestration platforms, it’s common to ingest and store every variable or event, but this quickly leads to oversized indices and inflated costs. Focus on indexing essential fields, such as process status, identifiers, and relevant business data. Exclude transient or verbose logs that don’t serve long-term analytical needs.

Another key area is data retention and tiered storage. Using hot/warm/cold tiering allows older, infrequently accessed data to be moved to lower-cost storage. NTConsult often configures historical indices to migrate automatically to warm nodes after 24 to 48 hours, preserving visibility while reducing reliance on high-performance infrastructure.

Query discipline is also essential. Poorly filtered or overly broad queries degrade performance and drive up compute usage. Always apply filters like time ranges and process IDs. Avoid unnecessary full-text search when exact matches or keyword fields will suffice.

From an architectural perspective, custom shard and replica settings per index can greatly improve efficiency. Default configurations treat all indices the same, but different use cases demand tailored strategies. Lighter indices should use fewer shards and replicas, while high-throughput logs may benefit from distributed reads and writes.

Finally, use monitoring tools like Elastic APM to gain visibility into application interactions, query behavior, and bottlenecks. Combined with dashboards in Grafana or Kibana, this gives your team actionable insight to keep the stack healthy.

These practices are most effective when tailored to actual orchestration demands, ensuring that Elasticsearch remains a source of insight, not overhead.

Should you host Elasticsearch in the cloud, on-prem, or hybrid?

The decision to host Elasticsearch in the cloud, on-premises, or in a hybrid model has direct implications for cost management, performance, compliance, and scalability.

Each option aligns with different operational requirements across industries such as finance and telecom. The table below presents the main characteristics and considerations for each deployment model:

Deployment ModelBenefitsTrade-offsBest For
Cloud (Elastic Cloud / AWS / GCP)Rapid deployment
Auto-scaling and managed infrastructure
Integrated security and backups
Higher long-term cost
Less control over tuning
Compliance risks for sensitive data
Fast-scaling teams, cloud-native environments
On-Premises (Self-Hosted)Full control over config and data
Better for strict compliance
Predictable cost for stable workloads
Higher operational burden
Requires skilled internal team
Limited elasticity
Regulated industries, legacy-heavy environments
HybridFlexibility to segment workloads
Combines control and scalability
Eases cloud migration
More complex architecture
Requires strong governance
Integration challenges
Enterprises with phased cloud strategies or mixed system dependencies

Each deployment model, cloud, on-premises, or hybrid, requires careful consideration of technical constraints, regulatory requirements, and long-term architectural goals. Choosing the right approach depends on how Elasticsearch fits into your broader orchestration and operational landscape.

How NTConsult enables efficient Elasticsearch orchestration

Implementing Elasticsearch is just the starting point, what defines long-term success is how well it’s integrated into your orchestration architecture. At NTConsult, we go beyond tool deployment to engineer solutions that are fast, scalable, observable, and cost-efficient.

Our approach starts by recognizing that automation alone doesn’t guarantee results. When workflows are poorly modeled or lack orchestration awareness, even the most advanced stack will generate noise, not insight. That’s why every Elasticsearch engagement we lead is grounded in architectural alignment with process behavior and operational needs.

We bring deep expertise in process orchestration, integrating workflow engines with Elasticsearch to enable real-time visibility without overloading infrastructure. This includes customizing shard strategies, lifecycle policies, and dashboards according to process behavior and business requirements.

Our teams also work across hybrid and multi-cloud environments, ensuring resilient and compliant Elasticsearch setups that adapt to performance requirements and regulatory constraints. From building tiered indexing pipelines to restructuring job worker models, we handle both the infrastructure layer and the orchestration logic it supports.

Most importantly, NTConsult acts as a long-term strategic partner. We don’t just configure and leave, we stay involved in evolving your orchestration architecture, monitoring performance, and supporting your future roadmap, including AI and intelligent automation.

Efficient Elasticsearch orchestration requires technical precision, business context, and delivery ownership. That’s the value NTConsult brings.

Elasticsearch is a powerful engine for enterprise observability and automation, but when misconfigured or poorly integrated, it becomes a hidden cost sink. This is especially true in BPM-driven environments, where large volumes of data flow through orchestration layers that demand architectural precision.

As this article has shown, the challenge isn’t the tool itself, it’s how it’s implemented. Default shard settings, unrestricted data ingestion, and inefficient workflows can quietly inflate infrastructure costs and reduce system performance.

NTConsult has helped organizations reverse this trend. Through real-world projects, we’ve delivered up to 70% cost reduction, improved stability, and long-term scalability, all without compromising visibility or functionality.

If your Elasticsearch setup is growing more expensive or harder to manage, it’s time to take a closer look.

Discover how much your Elasticsearch implementation is really costing you. Schedule a no-obligation architecture review with NTConsult and uncover savings opportunities of up to 70%.

To share

Related Posts

Orchestrating digital identity in financial services

Orchestrating digital identity in financial services

Digital identity is a dynamic, multi-dimensional representation of individuals and entities, combining data, permissions, behavior, and system interactions across the organization. In sectors like financial services, where regulatory...

Agentic AI in insurance: boosting ROI with smart AI

Agentic AI in insurance: boosting ROI with smart AI

The insurance sector is under growing pressure to modernize. Modernization concerns incremental automation, as well as to implement systems capable of autonomous, context-aware decisions. That’s where agentic AI stands apart. Unlike...