وظیفه‌ی دریافت درخواست‌های کاربر و تشخیص Node مورد نظر برای اجرای عملیات توسط این مدل از Node صورت می‌گیرد.
To prevent the queries and aggregations from creating instability in your cluster, coordinator (or client/proxy) nodes can be used to provide safe communication with the cluster.
برای جلوگیری از ایجاد ناپایداری درخواست‌ها و تجمع درخواست‌ها در کلاستر ، می توان از گره‌های هماهنگ کننده (یا سرویس گیرنده/پراکسی) یا همان coordinator Node برای ایجاد ارتباط ایمن با کلاستر استفاده کرد.
این مدل از Node یک‌سری خصوصیات دارد که در ادامه به آن اشاره می‌کنیم.
به راحتی می‌توان از کلاستر جدا گذاشته شود چرا که به عنوان مثال نقش Master Node را ندارد یا حاوی اطلاعات و داده نمی‌باشد.
چون در خط مقدم درخواست‌ها قرار می‌گیرد لذا از بی‌ثباتی یا ناپایداری Node ها جلوگیری می‌کند. (بعضی مواقع تعدادی زیادی کاربر یا یک کاربر درخواست‌های متعدد زیادی را به سمت کلاستر ارسال می‌کنند.)
از آنجا که coordinating node نوعی Master Node حساب نمی‌شود لذا سربار یا OverLoad ای که ممکن است بر روی آن ایجاد شود، ارتباطی با کلاستر نداشته و کلاستر را ناپایدار نمی‌کند.
اگر برنامه‌ای که درخواست‌ها را به سمت کلاستر ارسال می‌کند در کنار خود (بر روی سرور خود) دارای coordinating node باشد. (یعنی سرور برنامه همان coordinating node باشد.) آنگاه سرور برنامه (منظور برنامه‌ای فرضی که درخواست‌ها را به سمت Elasticsearch ارسال می‌کند.) از سرعت عمل بالاتری دارا خواهد بود. (چرا که در غیر این صورت اول درخواست از سرور برنامه به یک سرور تحت عنوان coordinating node ارسال شده و از آنجا به سمت کلاستر ارسال می‌شود. پس اگر سرور برنامه همان coordinating node باشد ، آنگاه سرعت عمل بالاتر می‌رود.)
بدون هیچ تغییری درون کلاستر می‌توان coordinator node ایجاد و اضافه کرد.
در صورتی که یک کلاستر فاقد یک سرور تحت عنوان coordinating node باشد آنگاه درخواست به سمت هر سروری (هر Node) که ارسال شود. (این قابلیت وجود دارد ! حتما لازم نیست کلاینت درخواست‌ها را به سمت Master Node ارسال کند.) آنگاه همان سرور و Node تبدیل به coordinating node نیز می‌شود.
لذا در درجه‌ی اول سرور یا Node مورد نظر در زمان دریافت درخواست‌ها ، وظایف مربوط به coordinating node را انجام می‌دهد که این وظایف به شرح زیر است :
تصمیم می‌گیرد که درخواست به سمت چه Node و Shard ای ارسال شود. (ممکن است خودش باشد یا ممکن است یک Node دیگر باشد.)
چگونه جواب Node های مختلف را با یکدیگر merge یا ادغام کند.
کی تصمیم بگیرد که عملیات مربوط به درخواست به اتمام رسیده و جواب حاضر است و آماده برای ارسال به سمت کلاینت.
