# Server load for different calls

**URL:** <https://forum.heroiclabs.com/t/server-load-for-different-calls/3890>\
**Category:** Game Design\
**Tags:** server-framework, authentication, golang\
**Created:** [May 23, 2023, 7:54pm UTC](https://forum.heroiclabs.com/t/server-load-for-different-calls/3890 "2023-05-23T19:54:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![j4c0b](https://avatars.discourse-cdn.com/v4/letter/j/3ab097/32.png) [@j4c0b](https://forum.heroiclabs.com/u/j4c0b)\
**Post date:** [May 23, 2023, 7:54pm UTC](https://forum.heroiclabs.com/t/server-load-for-different-calls/3890/1 "2023-05-23T19:54:37Z")

</div>

Hello, we want to use a gameplay server in Unreal for communication with the Nakama server in Golang.

We want to write players’ data (for example 10KB) only from our gameplay server.  
I’d like to know how big **server load** mean for:

1. call the API **WriteStorageObjects()** with Session and data.
2. call the **RPC** function with **Session** and data. The data are saved into the Storage in the RPC function.
3. call the **RPC** function with **Http\_Key** and data. The data are saved into the Storage in the RPC function.

Which option has the lowest load on the Nakama server? (could you give me some graphs or numbers?)  
I suppose the API with the Session is more complex to process, right?  
Which option is most secure?  
Which option is the most commonly used in the games?

---

<div class="post-metadata">

**Author:** ![tom](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.heroiclabs.com/tom/32/676_2.png) [@tom](https://forum.heroiclabs.com/u/tom)\
**Post date:** [May 24, 2023, 12:10pm UTC](https://forum.heroiclabs.com/t/server-load-for-different-calls/3890/2 "2023-05-24T12:10:29Z")

</div>

Hi @j4c0b,

For server to server communication we would recommend using an RPC and using a HttpKey for secure communication between your Unreal server and Nakama.

There is negligible performance impact between the 3 options you have proposed, but option 3 would be the recommended approach for S2S communication.
