Unidraw – a two-year journey

Hello! I'm Georgiy, a developer of the team that created Unidraw. I'll tell you a story about how we were looking for a tool for collaborative sessions on a virtual whiteboard. At first we deployed an open source solution, but then our load grew so much that we had to write our own. The article is about how the product began, what it is like now, and what we want to see it like in the future. There will be technical data, beautiful templates and the story of our main mistake.

Finding suitable solutions

We constantly use services with virtual boards, we settled on one option, but since 2022 we have been looking for an alternative. It is important for us that we can:

1. Conduct a retrospective

2. Make quick sketches of mockups that don't require design work

3. Draw architectural diagrams for discussion

4. Conduct online meetings with visualization of artifacts

5. Train colleagues

We considered various options, including BoardOs, but when we contacted them, they replied that they were not planning development for Russia, and were localizing their application only for China.

The solutions found had restrictions on the number of accesses to the boards, or they solved highly specialized problems.

At the same time, help came from our architects, who showed an Open Source project with P2P encryption of data transmission. Based on it, we decided to build our own service analogue with the ability to share links, save results in an account on the server and add recipients to the content of the board.

The open-source solution offered:

• one board maximum;

• support of collective sessions;

• storing the board in the user's browser.

Technical details of the solution:

• socket.io to synchronize changes between users;

• there is no single source of truth: all clients store the state of the board;

• the client has a Reconciliation mechanism that can merge changes from different users;

• Board updates are tied to the React lifecycle.

First steps of a new product

Taking an open source project as a basis, we created an account in which the user sees all the boards he created and the projects into which he could distribute these boards.

In the office, you can share boards, give general access to the entire project with boards with the distribution of rights to read or edit – not just one board, but all boards of this project at once.

Task number one was to set up persistent board storage. The technical decision was made in favor of speed of implementation in order to test the MVP and understand how popular the application could be, therefore:

1. The board was saved as a whole (JSON object) in the database every 20 seconds.

2. There were no locks during collective sessions; each client performed the save independently of each other. A small load of 1,500 users allowed us to do this.

3. In collective sessions, a newly logged in user received board data not only from the database, but also from other users via a socket. Therefore, in the worst case, the data in the database is out of date for 20 seconds.

We launched the service at the end of September 2022 and did not do any internal marketing other than the “tell a friend” method. In the first month, we received 250 consistently using the service.

The number of users grew organically – links to boards were passed from hand to hand. During this time, we solved the problems of developing functionality:

• made links to a place on the board: if, after passing this link to another user, he pastes it into the browser, the board will open in the place indicated by the creator of the link;

• added frames and stickers;

• added Color Picker, expanding the possibilities of color differentiation of elements on the board;

• added snap objects – lines that allow you to position elements relative to each other.

At this stage, we began to receive messages that the system fully satisfied their needs for solving a large number of tasks for which they used Miro and other systems. For example, people started coming to us from Storm BPM, draw.io and others.

The application gradually gained momentum. In terms of MAU by February 2023, we came to values ​​comparable to the number of users who were using Miro at the time when we wanted to buy their license for the company. And by the beginning of March we crossed the threshold of 2000 MAU.

The increasing load no longer allowed the application to work according to the scheme that was initially chosen for the backend – storing complete board models in one record. We were able to live with this scheme for no more than a year.

We came to the second iteration with a new solution:

• abandoned the storage of boards entirely: it is necessary that each object on the board be stored and transferred separately;

• Databases have become the only source of truth;

• changes in each object were recorded immediately, and not once every 20 seconds, as was before;

• a user could come in, query board data from the database, and be confident that the data was up to date, without waiting for synchronization with other users.

Figures inside the bank for two years:

• > 75 thousand boards;

• > 30 thousand users;

• 3.5 thousand unique users per day;

• relatively small amount of data: 400 GB;

The architectural diagram can be view also in Unidraw.

Technical details of the project

Frontend numbers: the current number of cyclic dependencies in the project is ~940.
We are gradually moving to FSD – Feature-Sliced ​​Design to build a scalable system and move away from the spaghetti code that we got from opensource.

It may seem that we are criticizing the code we took. In fact, we just took cool developments and made them even better.

Reasons for switching to FSD:

• there was no idea under the project structure;

• there was no uniformity;

• there was no composition, which leads to huge files and a large number of circular dependencies;

• difficult to work with code: difficult to read and understand connections, difficult onboarding for beginners;

• there is no scalability at the structure level – while developing an established structure, it would be necessary to increase the already large modules.

FSD is the most successful implementation of onion architecture on the front end:

• modules are clearly divided into areas of responsibility;

• it is easier to resolve cyclic dependencies;

• modules are small due to good decomposition;

• uniformity of structures – the project is decomposed according to a clear principle, so it is easy to find and add files;

• It’s easier to understand what a project is in layers; the cognitive load when developing new modules and maintaining old ones is significantly reduced;

• simple onboarding of new employees.

Disadvantages: any approach that solves problems of this level requires certain qualifications. It is necessary to cultivate an understanding of good architecture through the transfer of knowledge and experience, and then also monitor compliance with the principles. It takes time and can also cause resistance.

Rendering graphics. We used the Canvas API in the past and it had several advantages:

• Easy to learn: API that doesn't require advanced rendering knowledge. A large number of developers are familiar with it at least at a basic level.

• Anti-aliasing that works without additional tools.

• Browser support: works in all browsers, even older ones.

The main disadvantage of the Canvas API compared to WebGL is performance, since the Canvas API uses the CPU for rendering, while WebGL uses the GPU. This is especially noticeable on boards with a large number of elements.

We also considered the option of switching to KonvaJS. This is a complex and time-consuming process, which, despite its advantages, could lead to performance degradation. We decided not to rewrite the application for the new library, but to refine the solution:

• Use techniques used in KonvaJS in a ready-made application. For example, splitting into layers, functions for rendering and editing the text of elements, and the like.

• Rework the existing code base to meet the requirements we need.

To speed up rendering, we decided to switch to WebGL rendering. We analyzed popular libraries and frameworks for browser rendering, among which we chose PixiJS. Other options were not suitable for the following reasons:

• ThreeJS is primarily designed to work with 3D graphics. Most of the functions will not be used, but will only perform additional calculations. The vast majority of official examples are in 3D.

• FabricJS. No WebGL support.

• PhaserJS, BabylonJS, PlayCanvas are designed primarily for games – focused on working with sprites. They have poor capabilities for working with graphic elements.

PixiJS is a 2D graphics rendering engine. You can animate and create interactive graphics with it, draw applications, and it has a good API. It's also easy to adapt to your coding style.

Pros of switching to PixiJS:

• Significant performance gains. We created a demo of Whiteboard with basic unoptimized PixiJS rendering, which showed an 8x speed increase.

• Created and optimized for working with 2D graphics.

• Time-tested solution with a large community (Miro also uses PixiJS).

• There is a devtools extension for debugging.

• There are additional libraries for more advanced rendering, anti-aliasing and animations.

• It is possible to transfer hit-detection to the PixiJS event model.

• It's easier to write code without having to maintain a “virtual” Canvas.

• Batching for drawing graphic elements is used (combining several separate small calls into one large one).

• There is a built-in caching mechanism that speeds up rendering even more.

Backend features. Old architecture:

• withstood only 1,500 users (X DAU);

• generated > 1 TB of data in one year (with 1,500 users);

• up to 10 people on one board (with delays);

• inaccessibility of the entire system with 30+ people on a medium-sized board (> 1 MB).

With the new architecture we have:

• Unlimited number of users (horizontally scalable).

• 400 GB in two years in T-Bank (we optimized the data model, began to store not entire boards, but separate objects).

• Large group sessions on one board have no impact on the system as a whole.

• We do not send optimistic changes to clients until we write them persistently. A very cheap method, and works well with a relatively small load.

• Stateless – application with fast recovery time.

We use VPA – Vertical Pod Autoscaling because we try to take a conscious approach to resource utilization. Using VPA, you can automatically determine how much RAM, CPU, and other resources to allocate to your application.

Cursor movements used to be sent every 33 ms, which in theory allows for 30 fps. In practice, smoothness without additional processing left much to be desired; with network delays or rapid movements of participants around the board, the movement of the cursors looked jagged.

We increased the interval to 200 ms and began to move the cursors algorithmically: we took two points in time and independently calculated how fast to move the cursor. Despite the fact that we now send data 7 times less often, the real smoothness felt by the user has become higher.

One cursor movement event weighs 200 B. The weight of the event can change, for example, if the user selects an object or moves it. If we select 16 objects and move them, the message size is already 430 V. The RPS at the peak is 80, and the number of movement operations on the board is 250/s.

There is still room for improvement in rendering speed. We plan to separate the board state from the React lifecycle, change the state control via ComponentDidUpdate and make our own separate Model Change Flow. We also want to optimize very large circuits so that there is no display degradation during Zoom.

The main mistake along the way

We were not ready for a large number of users. Paying attention to working with the visual component, we expected to optimize the server for exchanging messages about changes in model elements a little later.

The data transfer model itself, inherited from the Open Source solution, was unsatisfactory: the entire board model with all its elements was transmitted over the network between recipients working with this board. This led to artifacts when more than five people appeared on the board, and put a high load on the data transfer server.

We were aware of this problem and wanted to completely rewrite the service after we expanded the functionality for the client with new tools. But the application began to be used for presentations of various ideas at meetings, and once it was used at the internal Demo Day event, where attention was paid to our application itself.

After that, we experienced a double increase in users – just over 2,500 WAU (5,000 MAU at the end of the month). And such a number of users put a significant load on the server.

This impacted the backlog and we had to urgently resolve the networking issue.

We had to reduce the amount of data for each element, change the model synchronization function, and reconsider the message passing method.

The message passing method was made so that changing one element within one chunk led to an update on the server and recipients of only this element and did not lead to the transfer of the entire model with the changed element.

Before us was a diagram in which the entire board model was saved in its entirety. In this case, the operation was performed by all users who are on the board. If a user changed an item on a board containing 1,000 items, the payload in this case was 0.1%.

We needed to maximize payload and improve performance.

The task was complicated by the fact that the board data was encrypted with end-to-end encryption and ideally we would like to make all the changes without downtime.

We made it so that not the entire board is updated, but each change to an element is saved separately.

Cases of using Unidraw

Retrospective — A regular event within IT teams to review the previous workweek or project iteration to identify successes, challenges, and ways to improve future work.

There are many types of online retrospectives. Here are some examples:

• Carousel of ideas. Participants write ideas on cards and discuss them in a circle.

• Decision tree. Problems are written as branches of a tree, and solutions are written as leaves.

• 4-Quadrant Model. Participants divide problems into four quadrants: important and urgent, important but not urgent, not important but urgent, not important and not urgent.

Unidraw is often used to build strategies because it simplifies communication, stimulates creative thinking and increases engagement.

Active participation in completing Unidraw makes the strategic planning process more interactive and interesting for participants. Here are a few ways it is used.

Visualization of goals and mission:

• Mind Mapping. Create a brainstorming session to visualize the company's purpose, its values ​​and key areas of strategy.

• SWOT analysis. Recording strengths, weaknesses, opportunities and threats on selected sectors of Unidraw, which helps to clearly see the company's position in the market.

Brainstorming and idea generation:

• Brainwriting. Participants take turns writing down their ideas on sticky notes, which are posted on Unidraw for group discussion.

• Scenario design. Development of possible scenarios for the company's development and their impact on the strategy.

Process structuring and planning:

• Kanban board. Visual representation of tasks, development stages and progress for each strategy area.

• Visualization of the project execution process. Used to monitor how projects are progressing and whether they have crossed a timeline relative to percentage completion.

• Gantt Chart. Creating a schedule for completing key tasks and stages of strategy implementation over a certain period of time.

Teamwork and joint decision:

• Sticky Notes. Using colored sticky notes to indicate priorities, categories, or opinions on various aspects of strategy.

• Round table. Unidraw serves as a central tool for discussing ideas, commenting on proposals, and making collaborative decisions.

Visualization of results:

• Pivot table. Key findings and decisions made during the strategy session are organized on Unidraw using a sticky note sorting table and can be shared via a link to this board.

• Visual graphics. Presentation of data on key metrics, strategy progress or results of its implementation.

Unidraw is often used in mentoring sessions for visualization when explaining different situations that a protégé may encounter.

Planning and goal setting:

• Setting goals. You can write down general mentoring goals or specific goals that the mentee wants to achieve over a certain period.

• Creation of Roadmaps. Visualize an action plan with milestones and key activities to track progress and adjust the path as needed.

Discussing problems and developing solutions:

• Mind Mapping. Using it, mentor and mentee can work together to analyze a problem, break it down into its component parts, and generate possible solutions.

• Sticky Notes. Each solution option can be assigned a colored sticker with a brief description of the pros and cons. This helps make comparison and choosing the best solution more interactive.

Exchange of knowledge and experience:

• Sharing Knowledge. You can jot down key phrases from discussions, links to useful resources, or lessons learned from your mentor's experience. This will help the mentee remember the information and apply it in future work.

Progress tracking:

• Kanban board. Helps visualize the current state of work on tasks and progress towards achieving mentoring goals.

• To Do, In Progress, Done – stages for each task.

Collecting feedback:

• You can create a section to collect feedback from the mentee on the progress of mentoring, which will help the mentor improve his work and make it more effective.

Unidraw can be used for a host of other tasks. We hid another list here:

• Building a Road Map based on tasks. Sharing the link with all participants is quite simple, and within the framework of group discussions, the weak points of the selected plan can be identified.

• Tutoring. Due to the ability to draw with a pencil, save templates, insert pictures and draw primitives, the tutor can explain subjects to the student online, while keeping all the materials in the office and returning to them if necessary.

• Business processes. Make a visualization of business process diagrams, drawing not only BPMN diagrams, but also simpler visualizations to explain the essence of the tasks and the architecture and design of processes.

• Mockup. Unidraw is used as a simple version of Figma, in which diagrams can be used to explain the construction of a design concept. In many cases, if teams already have their own design framework, a layout of the necessary blocks is enough, and Unidraw is a good, simple tool with a low barrier to entry into the tool for your business.

• C.J.M. Research. Building a customer journey is one of the good analytical tools for business and identifying weaknesses in a business process. By writing down notes from your customer research on sticky notes along this path, you can easily explain problem areas to your team colleagues.

• Description of the structure, personnel management. Unidraw makes it easy to visualize organizational design, which increases transparency in the company for colleagues, especially due to the ability to collectively discuss this design. This approach eliminates the risks of conflicts when restructuring an organization.

• OKR. Visualizing common goals and discussing them with the team within one board allows you to save not only the goals themselves, but also artifacts of the discussion, problems associated with achieving goals.

• Software architecture, Domain-Driven Design. Unidraw is used to visualize software architecture and conduct DDD sessions. Due to the infinite space, architecture and DDD diagrams can be drawn within a single board, which, using board links and search, makes it easy to navigate throughout the entire diagram.

I'll leave it link to open kanban metrics boardso you can see how everything looks in action.

Voting for new features

As the internal user base grew, requests for work-related changes began to gain a powerful influence. Using ratings, suggestions and questions, we modified our Road Map to achieve these goals. At the same time, the backlog of tasks clearly grew faster than the growth of the team’s capabilities, which led us to the decision to expand the team, as well as the selection of new features taking into account the existing functionality.

One of the requests was to add a new work for the arrow mechanics, the desire to make a simpler interface, adding pictures in large quantities and several at a time, adding bold, italic text and links that can be inserted directly into the text.

But we moved the ability to create objects to the backlog, because using Hotkeys, users were able to quickly create the necessary elements and without visual control for these purposes. We do not postpone such convenient features forever, but only for a while in favor of the most popular functions.

I would like to note that our company did not have any bans on the use of other applications, and the high Retention (above 65%) together with the growth of MAU gives the team a great impetus for further development of the product.

Our plans

Our task is to make collaboration as comfortable as possible for people.

The presentation module will be completed. We will add it because there is an internal need.

We will expand the story with the mobile version, because we have a lot of mobile users. But we are also planning some basic things: adding reactions, complex widgets, access via a link without registration, drawing by clicking on a point from an object.

We try to hear our users and improve the product together with them, so launched a telegram channel. Use it and leave feedback on improvements!