Backend Refactoring

[bastibock]

In this thread we want to discuss the structure and development of the new backend class.

@PietropaoloFrisoni please feel free to share the ADR based on your internal discussions!

[PietropaoloFrisoni]

Thanks @bastibock .

I paste below the ADR that I originally created as docx document (only shared within IQM) as Markdown source code

[PietropaoloFrisoni]

Architecture Decision Record

ADR-0001: Qrisp Backend Abstraction Layer

---

Field	Value
ADR Number	ADR-0002 (Second version)
Title	Qrisp Backend Abstraction Layer
Status	PROPOSED (with open questions)
Date	06/04/2026 (First version was dated 20/02/2026)
Authors	Pietropaolo Frisoni, member of the Qrisp team at IQM (every other contributor/author is welcome)
Stakeholders	IQM, Eclipse Foundation, External Hardware Vendors, Qrisp Community
Target Release	Ideally, ~2/3 months from date of issue

---

1. Context and Problem Statement

Qrisp is a high-level quantum programming framework that must be able to execute compiled quantum circuits on a wide variety of backends: local statevector simulators, cloud-based simulators, and real quantum processing units (QPUs) from multiple hardware vendors including IQM, IBM, IonQ, Quantinuum, and others.

The current backend implementation in Qrisp works as an extremely abstract "one-fits-all" tool. Essentially, the only existing feature is to send quantum circuits and receive results. At the moment, Qrisp has several internal backends (VirtualBackend, BackendClient, BackendServer, BatchedBackend, etc.) and some external ones (IQMBackend, QiskitBackend, QiskitRuntimeBackend, AQTBackend, etc.). The current structure is embedded into a network interface that was part of a requirement of the SeQuenC project during the early stages of Qrisp. This network interface will eventually never be used and should now be deprecated.

As a consequence, Qrisp lacks a stable, vendor-agnostic abstraction layer for backend execution. Each integration is implemented ad hoc, leading to a growing maintenance burden as the ecosystem expands.

We need to define a clean, minimal interface that:

• Any vendor backend can implement without imposing framework-specific dependencies.
• Supports both synchronous simulation and asynchronous hardware execution uniformly.
• Can be agreed upon jointly with IQM, the Eclipse Foundation, and other external partners within the available runway.
• Is simple enough for a small, relatively inexperienced team to ship, maintain, and evolve.

1.1 Team and Timeline Constraints

The Qrisp core team at IQM is small and does not have prior experience designing a backend abstraction of this kind. The target delivery is approximately two to three months from the date of this ADR. These constraints significantly influence the design philosophy: we favour simplicity and well-understood patterns over novelty, and we actively seek review from developers more familiar with quantum hardware (particularly from IQM and the broader open-source quantum computing community) before the interface is frozen.

1.2 Stakeholder Alignment Requirement

IQM and developers in the Eclipse Foundation must review and approve the interface contract before it is declared stable. Any breaking change after that point will require a revision process. This ADR is therefore both a design record and the starting point for that external review.

---

2. Decision Drivers

• Vendor neutrality. The interface must not encode assumptions specific to any single hardware vendor or gate set.
• Execution model coverage. Must support synchronous simulators, asynchronous cloud backends, and batch circuit submission without forcing a common blocking model on callers.
• Minimal surface area. A smaller API is easier to implement, easier to test, and easier for external vendors to adopt.
• Extensibility without breakage. Vendor-specific capabilities (calibration data, connectivity graphs, error rates) must be exposable without modifying the shared base interface.
• Approachability. External developers reviewing the interface should be able to understand it quickly. Standard, well-known design patterns are preferred.
• Time to stable release. The interface should ideally be shippable within two to three months, which rules out approaches requiring extensive prior art research or complex runtime machinery.

---

3. Considered Options

Option A — Adopt Qiskit's Backend interface

Qiskit defines a mature BackendV2 class that is already implemented by dozens of vendors. Adopting or mirroring it would give Qrisp immediate ecosystem compatibility.

• Pro: Large existing ecosystem of compliant backends.
• Pro: Well-tested and battle-hardened in production.
• Con: Introduces a hard dependency on the Qiskit SDK or requires copying significant amounts of Qiskit-specific types and infrastructure.
• Con: Qiskit's abstraction is tightly coupled to its own transpilation pipeline, which Qrisp does not use.
• Con: Vendor onboarding would require Qiskit knowledge, creating friction for non-Qiskit partners.
• Con: IQM engineers have already expressed frustration with some of the backend design choices made by Qiskit.

Option B — Adopt PennyLane's Device interface

PennyLane's Device class is another established abstraction, with a differentiable execution model tailored to certain algorithms.

• Pro: Differentiable execution might be relevant for some future Qrisp use cases.
• Pro: Good documentation and community support.
• Con: The execution model is tape-based (at least in non-capture mode, where it is jaxpr-based) and fundamentally different, making it a poor fit for Qrisp's compilation pipeline.
• Con: Vendor adoption would require PennyLane familiarity.

Option C — Define a minimal Qrisp-native Backend (chosen)

Design a thin, Qrisp-owned abstract base class that defines only the essential execution contract, following the same philosophy used by Qiskit's Job class: run_async() returns a job handle immediately, and the caller decides when to wait for the result. The internal mechanics of how that waiting is implemented are left entirely to each concrete backend.

• Pro: No external dependencies beyond Python's standard library.
• Pro: Vendor implementors only need to understand a small, self-contained interface.
• Pro: Full control over evolution; can adopt conventions from Qiskit or PennyLane selectively.
• Con: Requires effort to design well and to achieve multi-vendor consensus.
• Con: Ecosystem starts small; vendors must write new adapters rather than reuse existing ones.

---

4. Decision

We adopt Option C at this stage: a minimal Qrisp-native Backend abstraction. The necessity for a structured job management layer was notably emphasised by IQM engineers during discussions about this project in December 2025.

4.1 The Job-Based Execution Model

The core idea is that submitting a circuit to a backend returns a job handle immediately, without blocking. The caller then decides when and how to wait for the result. This is the same philosophy adopted by Qiskit: calling backend.run() in Qiskit returns a Job object, and the caller invokes job.result() when it is ready to receive the outcome. The name sometimes used for this pattern in software engineering is the "Future" or "Promise" pattern.

The base Job class defines only the abstract contract (the observable interface that all jobs must honour) and deliberately leaves the internal synchronisation mechanism to each concrete implementation. A local simulator may complete the job synchronously and return a result immediately; a cloud hardware backend will submit the circuit to a remote queue and poll for completion in a background process. From the caller's perspective, both are used identically.

This design also means that the question of asyncio compatibility is largely deferred to concrete backends. Because the base class does not prescribe how waiting is implemented internally, a backend built on asyncio primitives is free to override the waiting behaviour accordingly. This is the same approach Qiskit takes, and it is safer than baking a specific concurrency model into the shared interface.

In summary, and to be extremely clear: we propose to handle the Job interface the same way Qiskit does, with a few small non-invasive changes whenever appropriate. If you have any suggestions and/or alternative proposals, please let us know.

4.2 The run_async / run Split

A key design choice in the current implementation is the separation of the execution interface into two methods with distinct contracts:

run_async(circuits, shots) → Job is the abstract method that all concrete backends must implement. It returns a Job handle immediately without blocking. This is the primary entry point for new code and for any caller that needs the full job interface (status polling, cancellation, concurrent awaiting).

run(circuits, shots) → CircuitResult | list[CircuitResult] is a concrete convenience method provided by the base class. It calls run_async internally, blocks until the job completes, and returns the measurement results directly as plain Python dictionaries. The return type mirrors the input: passing a single circuit returns a single CircuitResult (a dict[str, Any]), while passing a list returns a list[CircuitResult]. This method exists primarily for backward compatibility with existing Qrisp code that previously called backend.run(circuit, shots) and expected a dictionary directly (so we want to avoid breaking changes).

Concrete backends implement only run_async. The run method is inherited from Backend, but it can also be explicitly overridden if necessary.

4.3 Key Design Choices

The following choices characterise the proposed interface at a conceptual level. Technical details are intentionally kept out of this ADR and belong in the code documentation and implementation notes.

• A backend accepts one circuit or a batch of circuits, subject to a hardware-defined limit on how many circuits a single job may contain, and returns a single job handle. How the circuits within that job are executed (sequentially or in parallel) is an internal decision of each backend.
• The job exposes its current lifecycle state (for example: initialising, queued, running, done, failed, cancelled) so that callers and tooling can reason about progress without blocking. JobStatus is implemented as a StrEnum, so status values are both human-readable lowercase strings and type-safe enum members.
• The base interface does not prescribe a shared circuit representation. Each concrete backend accepts the circuit types it understands. This avoids a much larger design commitment at this stage and is consistent with how Qiskit's BackendV2 works in practice.
• Hardware metadata such as qubit count, connectivity, supported gates, and error rates are exposed as optional properties. The absence of a value signals that the backend does not expose that information. This keeps the base interface hardware-agnostic while allowing vendor backends to provide richer data. Backend-specific capabilities not covered by the base interface should be exposed as concrete typed properties on the subclass.
• Status polling distinguishes between a live query (status(), which may involve a network call for remote backends) and a cached read (last_known_status, which never triggers a round-trip). The refresh() method updates the cache and returns the freshly fetched status, making polling loops explicit and network-efficient.

4.4 Error Signalling from result()

Rather than raising bare RuntimeError when a job fails or is cancelled, the interface defines two dedicated exception classes:

• JobFailureError — raised by result() when the job reached JobStatus.ERROR.
• JobCancelledError — raised by result() when the job was cancelled (JobStatus.CANCELLED).

Both are subclasses of RuntimeError, so existing callers that catch RuntimeError continue to work without modification. The dedicated types allow callers to distinguish failure from cancellation without inspecting the job status separately.

Concrete implementations are expected to call the provided helper _raise_for_status() inside their result() method once the job has reached a terminal state, rather than duplicating the exception logic.

4.5 Alignment with Qiskit's Philosophy

The job-based execution model described above is deliberately aligned with Qiskit's approach. Where Qiskit's Job interface was found to be a good fit, we follow it. Where Qiskit's broader BackendV2 interface was not a good fit (in particular, its coupling to Qiskit's own transpilation pipeline) we diverge. The goal is to learn from Qiskit's experience without inheriting its constraints.

5. Relationship to Established Design Patterns

The structure proposed in this ADR maps onto three well-known object-oriented design patterns as catalogued on Refactoring Guru. Recognising these patterns is useful because it gives reviewers and future contributors a precise shared vocabulary, and because it confirms that the design follows established and well-understood principles rather than introducing novel structure.

5.1 Job as a Virtual Proxy

The Proxy pattern provides a substitute or placeholder for another object and controls access to it, optionally performing work before or after the real object is reached.

Job is a Virtual Proxy for the execution result. The actual computation may be running on a remote QPU, in a background process, or may already be complete (the caller never interacts with any of that directly). Instead, it holds a Job handle and accesses the result through it only when it chooses to, by calling result(). The job lifecycle states (QUEUED, RUNNING, DONE, etc.) are the Proxy managing access before the real outcome is ready.

Notice that Refactoring Guru's Python implementation defines a separate Subject ABC from which both RealSubject and Proxy inherit. In our design, Job could potentially be that shared interface. That is, there is no separate Subject class because the "real subject" (the remote execution) is not a Python object at all. Collapsing the two into a single ABC is a potential deliberate simplification.

5.2 Backend and Job together as a Bridge

The Bridge pattern splits a class into two independent hierarchies. That is, an Abstraction and an Implementation, that can be developed and varied independently of each other.

Backend and Job form a Bridge in this sense:

• Backend is the Abstraction: it defines the high-level interface the caller uses (run_async(circuits, shots)).
• Job is the Implementation: it carries the execution handle and result retrieval logic.

The two hierarchies vary independently. For example, we could add a new backend (e.g. QuantinuumBackend) without changing the Job hierarchy, and we can introduce a new job variant without touching any backend. Neither hierarchy constrains the other.

The main structural difference from the textbook example on R.G. is in how the two sides are connected. In Refactoring Guru's Python example, the Abstraction receives an Implementation instance in its constructor and holds it as a permanent reference. In our design, Backend does not hold a Job at construction time. Instead, it produces one each time run_async() is called. The spirit of the Bridge (two independently varying hierarchies) is fully present; the wiring is a factory relationship rather than a constructor composition.

5.3 Concrete vendor backends as Adapters

The Adapter pattern makes an existing class with an incompatible interface work with client code that expects a different interface, by wrapping the existing class and translating calls.

Concrete vendor backends (such as IQMBackend (which is a WIP in a separate package) or IBMBackend) are Adapters. They inherit from Backend (the Target interface that Qrisp's client code expects) and internally wrap a vendor SDK (the Adaptee, whose native API is incompatible with Qrisp's interface). The concrete backend translates run_async(circuits, shots) into whatever the vendor SDK requires, without the rest of Qrisp knowing anything about it.

5.4 Summary

Pattern	Where it appears	What it expresses
Proxy (Virtual)	Job alone	A local placeholder that controls access to a deferred or remote execution result
Bridge	Backend + Job together	Two independently varying hierarchies: submission interface and execution handle
Adapter	Concrete backends (e.g. IQMBackend)	A vendor SDK wrapped to satisfy the Backend interface expected by Qrisp

These three patterns operate at different levels and are not mutually exclusive. The Proxy describes what a single Job is; the Bridge describes the relationship between the two abstract classes; and the Adapter describes how each concrete vendor integration fits into the overall structure.

6. Advantages and Disadvantages

Note: this section will be updated as the design evolves through the review process.

Advantages	Disadvantages / Risks
Hardware-agnostic: no vendor lock-in in the base interface.	No shared circuit representation: each vendor must handle Qrisp circuit types explicitly.
Zero external dependencies beyond Python standard library.
Uniform async API for synchronous and asynchronous backends via run_async.	No parallelism guarantee for batches: sequential vs. parallel execution is backend-defined.
run() provides backward compatibility for existing code without any changes required.	New ecosystem: existing Qiskit and PennyLane adapters cannot be reused directly.
Batch submission is supported natively.
Explicit job lifecycle states make progress observable without blocking.
JobStatus as StrEnum gives human-readable status values that are still type-safe.	Hardware metadata is untyped at the base level: schema agreement is deferred to vendors.
Dedicated JobFailureError / JobCancelledError let callers distinguish failure modes.	The team is designing this interface without prior experience, which carries a risk of structural mistakes that are costly to fix after the interface is frozen.
last_known_status and refresh() make polling loops network-efficient for remote backends.	The short runway limits the time available for external review and iteration.
The internal concurrency model is left to each backend, avoiding asyncio lock-in.
Minimal mandatory surface area for implementors: a single abstract method (run_async).

---

7. Risks and Mitigations

R1 — Interface frozen too early

Risk: The interface is stabilised before sufficient external review, leading to breaking changes shortly after release.

Mitigation: This ADR is intended as a basis for discussion before the interface is declared stable. After a review window, we hope it will also be useful for more experienced software engineers to understand the design rationale and suggest alternatives. We can also ship the first release with an explicit pre-release label so that callers are aware of the risk of changes.

R2 — Lack of team experience

Risk: The design contains structural mistakes (for example, a wrong choice of abstraction level, missing lifecycle states, or inadequate concurrency handling) that are hard to fix after the interface is frozen.

Mitigation: We actively solicit review from experienced developers in the quantum computing open-source community. We will document design rationale extensively in the codebase. We will write comprehensive tests covering synchronous, asynchronous, error, and cancellation scenarios before the interface is published.

R3 — Vendor adoption friction

Risk: Hardware vendors implement the interface incorrectly or inconsistently, leading to user-facing bugs that appear to be Qrisp bugs.

Mitigation: We plan to ship a reference test backend and a conformance test suite alongside the interface. This gives vendors a concrete compliance target and reduces the risk of silent incompatibilities.

R4 — Asynchronous execution compatibility

Risk: Backends built on asynchronous frameworks (for example, cloud SDKs that use non-blocking I/O) may not integrate cleanly if the interface makes assumptions about how waiting is implemented.

Mitigation: The base class deliberately avoids prescribing an internal concurrency model. Concrete backends are free to implement waiting in whatever way suits their execution environment. This is the same approach taken by Qiskit. If a future need arises for a dedicated asynchronous variant, it can hopefully be addressed in the future without breaking the existing interface.

R5 — Short delivery timeline

Risk: The two-to-three-month ideal window is insufficient to reach genuine multi-vendor consensus, so the interface ships without adequate external buy-in.

Mitigation: We will prioritise IQM and Eclipse Foundation reviews as the primary partners and treat other vendor agreements as post-v1 stretch goals. We can publish the interface under an explicit stabilisation-period notice in the changelog.

---

8. External Review Request

The Qrisp team explicitly invites developers (particularly from IQM and the Eclipse Foundation) to review this interface and provide feedback on the following open questions.

Open Questions for Reviewers

• Is the proposed Job lifecycle sufficient? Are there states specific to real hardware (for example, validation or transpilation phases) that should be standardised in the shared interface rather than left to individual backends?

  Answer:

• Should submitting a batch of circuits return a single job handle for the entire batch, or one handle per circuit? The current proposal returns one handle per batch submission.

  Answer:

• Should hardware metadata properties (qubit count, connectivity, supported gates, error rates) be formally typed in a shared schema, or remain loosely typed as proposed?

  Answer:

• Are there hardware-lifecycle concerns (for example, calibration refresh, session management, or credit and quota tracking) that should be reflected directly in the base interface rather than deferred to an extension point?

  Answer:

• Are there lessons from Qiskit's BackendV2 and Job design (positive or negative) that we have not adequately accounted for?

  Answer:

• Please write additional comments, suggestions, etc. in the space below.

Please submit feedback via comments and/or additions to this document.

---

9. Consequences

If this ADR is accepted:

• All existing Qrisp backend integrations must be ported to conform to the new interface. Concretely, each existing backend must rename its run() method to run_async(). The base class run() method handles the backward-compatible synchronous path automatically, so callers that use backend.run() require no changes.
• A reference test backend and conformance test suite must be shipped alongside the interface.
• A migration guide must be written for any users who have been relying on the existing backend structure.
• IQM and Eclipse Foundation must be engaged promptly after acceptance to begin the joint review process.
• The interface can carry an explicit pre-release label for a stabilisation window, during which breaking changes will require an appropriate discussion.

If this ADR is rejected or superseded:

• A new ADR must be filed documenting the alternative decision.
• In the interim, the backend abstraction problem remains unresolved and integrations continue to be implemented ad hoc.

---

10. References

• Qiskit BackendV2 documentation
• PennyLane Device class documentation
• Python concurrent.futures documentation (Future pattern reference)
• Qrisp source repository

[renezander90]

I have a question regarding the job-based execution model regarding how much it would be exposed to the user:

Will it still be possible to run a program via qv.get_measurement(backend=mybackend). In this case, there would be no access to the job?

Or would this then work for the user the "qiskit way":

qc = qf.qs.compile()
job = backend.run(qc)
results = job.results()
# and now we are stuck with an unprocessed result dictionary {"00101011":0.4, etc.}

or would get_measurement return a job (with post-processing):

job = qf.get_measurement(backend=mybackend)
result = job.result() 
# processed result dictionary {3.5:0.4, etc.}

A related discussion:

For execution via Catalyst on a PennyLane device (simulator, or potentially real backend) we enable passing the backend to the qjitdecorator: https://www.qrisp.eu/reference/Jasp/Simulation%20Tools/QJIT.html
I think this similar to how execution of programs on different backends is handled in PennyLane in general?.
(Note that, this pipeline is not related to our backend interface.)

Similarly, I would envision to enable providing a backend to the jaspify (or some other) decorator to run Jasp quantum programs:
(In the near term, this could be done via the post-processing extraction that @positr0nium implemented.)

@jaspify(backend=mybackend)
def main():
    qf = QuantumFloat(4,-1)
    h(qf)
    res = measure(qf)
    return res

(In this case, executing main() could also return a job which includes the post-processing; here: mapping bit strings to the QuantumFloat values.)

To put it in a nutshell, the main requirement would be not to expose circuit handling to the qrisp user (except for when the user chooses to work with QuantumCircuits instead of QuantumVariables).

[positr0nium]

tldr; QuantumVariable.get_measurement will still work.

I however believe that it is still reasonable to also have this job interface. The "we only do high-level" perspective is for sure a very clean one but it can make things difficult for people who use the SDK in different ways than we have been doing it. We also need to be capable to cater to them, otherwise we will become a niche framework.

[PietropaoloFrisoni]

Hi @renezander90 , thanks for the feedback!

The Backend infrastructure we are proposing defines how circuits are submitted to hardware and how execution results are retrieved at a low level. How QuantumVariable.get_measurement (or any other high-level Qrisp entry point) exposes this to the user is a separate design question (one about the Qrisp API layer, not about the Backend abstraction itself).

It seems to me that the two are compatible and can be designed independently.

Taking into account its name, current signature:

    def get_measurement(
        self,
        plot=False,
        backend=None,
        shots=None,
        compile=True,
        compilation_kwargs={},
        subs_dic={},
        circuit_preprocessor=None,
        filename=None,
        precompiled_qc=None,
    ) -> dict:

and the fact that this is heavily used (I have also seen this in the IQM demo notebooks), I think get_measurement should continue to return a processed dictionary, as it does today. This is the natural interface for users who are working with QuantumVariable objects and do not want to think about circuits or job handles. The job lifecycle can be handled internally, hidden from the user at this level. So I agree with your suggestion: we should not expose circuit handling to the qrisp user.

However, this convenience comes with an important constraint: a blocking get_measurement is only appropriate when the result is expected to arrive promptly (in practice, when using a simulator or a very fast backend). On real quantum hardware with multi-user queues, blocking the caller until a result arrives is not just slow, it is the wrong abstraction entirely (as IQM engineers already made us notice a few months ago). The result may not exist for hours or days, and without a Job handle the user has no way to persist their submission, monitor progress, or retrieve results in a separate session.

For those scenarios, the right entry point is backend.run() directly, which returns a Job immediately. Consider the two workflows that real hardware users need:

1. A user submits a job to a QPU with a long queue, finds out they are position 93, saves the job ID to a file, shuts down their computer, and returns the next day to retrieve the result once the job is done.

2. A user submits multiple jobs at once, shuts down their computer, and collects all results the following day.

Neither of these is possible through a method that blocks and returns a dictionary. But both work naturally through backend.run(). The two interfaces are complementary, not competing: get_measurement for the synchronous convenience path, backend.run() for the full async hardware path.

Regarding your third proposed option (that is, get_measurement returning a Job that includes post-processing) this is an interesting middle ground worth keeping in mind. It would give users the convenience of post-processed results while still allowing them to defer the blocking call. We could flag this as a design decision to revisit when we refactor get_measurement to work with the new infrastructure, rather than something to settle now.

As a side note, on the current signature of get_measurement: I think it carries too many optional arguments and should be refactored. The new Backend infrastructure gives us a natural opportunity to do that cleanly : )

[renezander90]

Thank you for your detailed reply!

I think we should keep get_measurement returning a processed dictionary (otherwise, this would be a huge breaking change), but we could think of a second get_measurement_job method returning a Job that includes post-processing.

[positr0nium]

Yes, thanks Pietro!
@renezander90 I would keep the get_measurement exactly how it is. A "post processing job" class makes things very complicated because then we have to pickle the post processing logic and possibly even store it to the hard-drive.
I think users who want to use the job feature are accessing the backends via the QuantumCircuit.run interface with possibly custom logic anyway. This type of experiment is much less about playing around with an "integrated algorithm" but much more with everything manually coded from user side. I understand that this deviates a bit from the philosophy that we have been following in Qrisp development, but as long as it doesn't interfere with our high-level stuff I don't see a reason why we should make this style deliberately complicated.
For Jasp-experienced users, we can even also put some examples on how to combine this with the post-processing feature.

[bruno-ah-um]

I have very little experience with Qiskit, but I think the proposed interface makes sense. I will be happy to review the implementation.

[PietropaoloFrisoni]

Hi team : )

I updated the ADR above and made a second version.

This version of the ADR reflects several implementation changes made since the first draft (most of them have been discussed on Mattermost with Raphael and other IQM's engineers):

• The most significant is the introduction of the run_async / run split. run_async is now the single abstract method that all concrete backends must implement, which returns a Job handle immediately.

• Two dedicated exception classes, JobFailureError and JobCancelledError, replace the bare RuntimeError that was previously raised by the result() blocking method.

• JobStatus is now a StrEnum, so status values are human-readable lowercase strings as well as type-safe enum members. The Job class also gains last_known_status, refresh(), and _raise_for_status() to support network-efficient polling and consistent error signalling in concrete implementations.

• Finally, the capabilities extension-point property has been removed from the base Backend class. Vendor-specific capabilities should now be exposed as concrete typed properties directly on the subclass.

As a final comment, I will start working on the Plasma-Sabre package while waiting for review(s) on the PR. This will probably suggest further improvements on the Backend structure, which can be implemented in the following PRs before the next release 👍