Conceptually, the architecture of Restspace is that a number of small internet-accessible web services run on a deployment unit, which may be a server or serverless function, each of which has a domain, e.g. in the diagram Incoming requests to a domain are routed to one of the services on the corresponding deployment unit using the path of the url. The service can then call other services either via an internal (and therefore effectively instantaneous) messaging system for services in the same domain i.e the same deployment unit, or over the internet for services in other Restspace domains, or 3rd party services.

This is in many ways the opposite of a technique for managing distributed computation called Remote Procedure Calling (RPC), where abstractions layered on networking make running code on a remote machine as simple as calling a method or procedure. The idea of this is to simplify what's involved in running code on multiple servers as much as possible by forcing internet services to behave like code.

Instead, Restspace counterintuitively insists that code modules running in the same process receive and return HTTP messages. In this way it makes code behave like internet services. While this would seem to make more work, it in fact has major advantages. It forces code modules to have very uniform interfaces, making code reuse much easier. Like RPC, it creates Location Transparency where there's virtually no difference in calling code on the machine you're on or another machine, allowing code to be easily distributed across machines in an optimal way and aiding scaling. Also when you create a code module that refers to or composes other code modules (e.g. Pipeline service), it can actually work with any service exposed on a url on the entire internet, because your model for a code module corresponds to the model of any internet service.