This idea is pop out after i have play around about socket communication, http rest api communication and some real-time connection. This just an idea won't always be most effective in production but you may try or improve from this ideal.

Tech Stack

Socket / Websockets / Message Broker at any languages.
Any languages & framework able to integrate socket.
Any Client can consume API.

Strcture sketch

|---------|
| Service | <======  |-----------------------|
|---------|          |                       |
                     |                       |
|---------|          |                       |               |------------|
| Service | <======  |   API Expose Server   | <==========>  |   Client   |
|---------|          |                       |               |------------|
                     |                       |
|---------|          |                       |
| Service | <======  |-----------------------|
|---------|

Structure Explaination

As u see there some microservice and one or more than one API expose server is available depend on your situation example for support load balancer, different api, outsource api or something.

Services

Service at here will be a socket / websockets server that. At service layer, we will work all action related to service their own only like payment process payment thing only. Service can connect each other but not suggested may messy at future when more nad more service coming. Because of we have multiple service to make it easier to build a request library for API expose server, we standardize the request format and response format etc.

Initial ( Connect to Service )

* Check socket handshake headers ( API_KEY or other authentication method )
* If authorize go on, otherwise reject unauthorize access.

Request

socket.request('GET_USER', 1);
socket.request('UPDATE_USER', 1, { name: 'Oska' });

Response

{
    "ok": true,
    "result": ''
}

or

{
    "ok": false,
    "error": {

    }
}

Api Expose

Most of the API will follow the basic CRUD endpoints and some action endpoints.

GET /users/1
GET /users/
POST /users
PUT /users/1
DELETE /users/1

METHOD /users/[id]/action_name
METHOD /users/action_name

When requested, api expose server will validate user authentication and run some service action via socket, most of the time service action won't have any updates because what they do are always same and only updated is API to support more action etc.

Version 1
* Payment via Payment Gateway ( support gateway A ).

Version 2
* Payment via Payment Gateway ( support gateway A, B, C ).
* Check user status is purchasable.

Version 3
* Payment via Payment Gateway ( support gateway A, B ).
* Check user status is purchasable.
* Check order has voucher used.
* Check item is still available.

As you see most of the time, we just added extra action from new service or addon for some features and payment service just have to make sure payment is work and return not support when is not supported anymore at specific version.

Why not use HTTP at server to service communication

As i know every request in http will include request headers, uri, response headers and response body because it's request-reply mode and longer time usage on this flow. But for socket / message broker, most of the time is just request ( action, body ) and response body.

Why suggest use socket at service side ( Javascript only )

Since we know javacsript is event loop drive, mean concurrent request incoming we can just use the nodejs emmiter to told other request that request is done for now and return directly to other concurrent same request, you may make this work together with cache.

Ideal Microservice Structure (1) - Socket