Safe Bidding 2.0 System

1. About the Client

• Agency: Public Procurement Service (PPS, 조달청)
• Target system: The external control domain of electronic procurement bidding
• Target users: Company staff who take part in electronic bidding
• Task: Improve processing speed and stability while maintaining the security of the bidding process

We took part in building the next-generation Safe Bidding 2.0 system.

2. Background

In electronic bidding for public procurement, a large number of companies connect at the same time at a set hour. Traffic concentrates in the few minutes just before the deadline, and if the system slows down during that time, some companies cannot bid at all. A single delay leads directly to a lost business opportunity for a company.

At the same time, this system requires a high level of security. Bid amounts must be protected until they are disclosed, the identity of the bidder must be verified accurately, and attempts to obtain other bid information by improper means must be blocked. If fairness breaks down, the procurement system itself is shaken.

Security and speed collide

The problem is that these two requirements push against each other. Strengthening security adds verification steps, and more steps mean slower processing. The longer the security module running on the bidder's PC takes to execute, the greater the burden on a user who is racing against the deadline.

In the existing system, the security module ran heavily and execution was delayed. When a bid deadline is imminent, this delay is not a mere inconvenience but a factor that prevents participation itself.

Conflicts with other programs

Another problem is the user environment. The PC of a bidding officer has several business programs installed. If the security module takes up a large share of system resources or interferes with other programs, conflicts occur.

When a conflict occurs, the bidding officer cannot tell the cause. Not knowing which program is responsible, they reinstall repeatedly while the deadline approaches. For the agency, inquiries surge and staff are tied up responding.

Setting the criteria for improvement

Safe Bidding 2.0 aimed to solve these two problems without lowering the level of security. The task was to raise execution speed, reduce conflicts with other programs, and strengthen the security of payment-related procedures.

In one line The task was to make it fast without lowering security. Giving up one of the two was not an option.

Constraints of a public system

A private service can announce a "recommended environment" and decline to support anything else. Public procurement cannot. The system must work on whatever PC a company that wants to bid is using, and if it works only in certain environments, that in itself becomes an imbalance in the opportunity to participate.

This constraint changes how development is done. It cannot be built on the assumption of the latest environment, and the other installed programs cannot be controlled either. It has to be designed to guarantee a minimum level of operation under any conditions.

The scope of verification also widens. Because checks have to be repeated across many combinations of environments, verification takes a larger share of the work than feature development. This is a general characteristic of public-sector projects.

3. Key Features

We redesigned the security processing structure and removed the causes of conflict that occurred in user environments.

Improved processing structure

We divided the security verification procedure into stages and distinguished the tasks that must be done in order from those that can run in parallel. If every step is processed serially, the time of each stage is simply added up, but when independent checks proceed together the total time taken is reduced.

We also cleaned up checks that were repeated unnecessarily. Items already verified within the same session are no longer checked again, and we found the sections where results can be reused and removed the duplication.

Reduced resource footprint

We reduced the resources the security module takes up on the user's PC. Parts that stayed resident and ran continuously were changed to run only when needed, and the data kept in memory was cleaned up.

When the resource footprint shrinks, the likelihood of colliding with other programs shrinks with it, because a considerable share of conflict problems originates in resource contention.

Removal of conflict factors

We found the points where interference with other business programs occurred and changed how they are handled. Behavior that affected the whole system was confined to the inside of the program, and assumptions about the external environment were reduced.

The environment of the user's PC cannot be controlled. Because there is no way to know which programs are installed, making the security module less dependent on the environment was the only solution.

Payment procedure security

We strengthened the security of the payment process connected to bidding. Sections where money changes hands require a higher level than other sections, and the processing results must be recorded clearly.

Main features

Running the security verification procedure

The system performs the verification procedure required for participating in a bid. The procedure is divided into stages, and tasks with no order dependency are processed together to reduce the time taken.

Removal of duplicate checks

Items already verified in the same session are not checked again. Repeated verification had been taking up a considerable share of the execution time.

Resource usage optimization

Processing that used to run at all times was moved to the point where it is needed, and memory usage was reduced. The program size was reduced as well.

Reduced environment dependency

Behavior that interfered with other programs on the user's PC was confined to the inside of the program. This is a measure to secure stability under conditions where installation environments vary widely.

Secured payment process

The security of the payment procedure linked to bidding was strengthened, and processing results are kept as records.

Error guidance

When a problem occurs, the guidance distinguishes the cause. If users cannot tell what stopped the process, they reinstall repeatedly, and with the deadline imminent this is critical.

Processing history records

The verification steps performed and their results are recorded. When a problem occurs, this provides the basis for checking at which stage the process stopped.

Compatibility verification

We checked operation across many combinations of environments. A public system cannot specify the environment its users use, so verification under a wide range of conditions is required.

How speed was improved

There are broadly three ways to reduce execution time: do less, change the order, or do the same work faster.

In a security system, the first option cannot be used. Reducing the items to be verified lowers the level of verification, and that bears directly on trust in the system. So we concentrated on the second and third.

Changing the order starts with checking the dependencies between steps. Each one has to be examined: must A finish before B can be done, or can they be performed independently? A considerable number of the steps that had been processed in sequence by convention could run in parallel.

Doing the same work faster meant removing duplication. We found the places where the same item was verified several times within one session and changed them to reuse the result.

How conflicts were reduced

Conflicts usually arise when two programs collide over the same resource. Reducing the resource footprint reduces the occasions for collision themselves.

Processing that stayed resident and ran continuously was changed to run only when needed, and the data kept in memory was cleaned up. As the program size shrank, the burden of installation and execution was reduced as well.

Confining behavior that affected the whole system to the inside of the program also had a large effect. The smaller the scope of intervention in the external environment, the less unexpected interference there is.

Execution status display

The system shows whether processing is in progress or has stopped. With the deadline imminent, if the screen appears frozen the user tries to force-quit, and that in turn becomes a problem.

Simplified installation

We reduced the number of steps in the installation process. Quite a few users install just before bidding, so installation itself has to be fast.

Time spent on verification

In this project, verification took a larger share than development, because a public system cannot specify the user environment.

Confirming that it works in one environment does not take long. The problem is combinations. With even a few variations each of operating system version, other installed security programs and network conditions, the number of cases to check grows quickly.

Since not every combination can be checked, we prioritized and verified the combinations that appear frequently in real user environments. The types of inquiries received for the existing system were the basis for setting these priorities, because which problems actually occurred in which environments is the most accurate information.

How the figures were confirmed

The figures of 64.3% for speed and 86.4% for conflicts are the result of comparing before and after the improvement under the same conditions. A comparison is meaningless if the environments differ, so we measured by running the same procedure repeatedly in the same environment.

The reduction in conflicts was based on frequency of occurrence. Conflicts appear only under certain conditions, so they cannot be confirmed in a single run; the number of occurrences over repeated runs has to be compared.

The headroom gained when inquiries fall

The change that appears immediately when conflicts decrease is a drop in inquiries.

When inquiries concentrate at the bid deadline, all of the support staff are tied up. Inquiries from other users pile up even while a call is being answered, and it becomes hard to handle the truly urgent cases first. Because the deadline is fixed, if the response is late that user misses the bid.

When inquiries fall, there is headroom to respond properly to the ones that remain. This difference is more substantial than the reduction in the number of cases. Distinguishing error causes in the guidance follows the same reasoning. If users can check the cause on screen, the inquiry does not arise in the first place.

Retry handling

When the process is interrupted by a temporary problem, it continues from where it stopped instead of starting over. Repeating the whole process just before the deadline is a heavy burden on the user.

Environment pre-check

Before execution, the system checks whether the required conditions are met. Telling the user before starting, rather than failing partway through, leaves the user time to respond.

4. Outcome

Execution speed improved by 64.3%. Processing time fell as the security verification procedure was restructured and duplicate checks were removed. Because bids concentrate just before the deadline, this difference determines whether participation is possible.

Program conflicts reduced by 86.4%. This is the result of reducing the resource footprint and lowering environment dependency. Fewer conflicts mean fewer user inquiries, and the agency's support burden falls as well.

Payment process security strengthened. We raised the level of security in the payment section linked to bidding and made the processing results recorded.

The core of this project is that speed was improved without lowering security. Had the approach been to reduce the items verified, speed would have risen easily, but the foundation of the system would have been shaken. Because we approached it by reorganizing the order of the steps and their duplication, we were able to reduce the time while maintaining the level of verification.

Core design It did not become faster by verifying less; the same verification was changed to run in a more efficient order.

Characteristics of a system with a deadline

In a typical service, traffic is spread across the day. Electronic bidding is not like that. The deadline is fixed, and most participants arrive just before it.

In this structure, averages do not mean much. Even if the system runs fast most of the time, if it slows down just before the deadline it has failed. Conversely, even if the average is somewhat slow, there is no problem as long as it is stable at the deadline.

So we set the criterion for improvement to the worst case, not the average. The goal was to reduce the slowest case and to eliminate situations that fail only in certain environments. Reducing the average and reducing the worst case call for different methods. The former means making frequently used paths faster; the latter means finding and removing the causes of delays that occur rarely.

The time users spend waiting

Perceived speed differs from actual processing time. The same three seconds feel long if nothing changes on screen and short if progress is visible.

For a user racing against the deadline, this difference is large. If the process appears to have stopped, they try to force-quit, and then they have to start over. Displaying the execution status was a necessary measure separate from the performance improvement.

Operation after the improvement

Performance improvement does not end with a single piece of work. Over time, features are added and user environments change.

That is why keeping a processing history matters. If there is a record of how long each stage took, the cause can be narrowed down when things slow down later. Without records, everything has to be measured again, and in the process the team ends up chasing problems that cannot be reproduced.

The same applies to changes in user environments. When a new security program comes into wide use, conflicts that did not exist before can appear. A response is possible only if there is data showing under which conditions the problem occurred.

5. Technical Overview

Area of application: A security module that operates in the external control domain of electronic bidding. It runs on the user's PC and integrates with the bidding system.

Processing structure: The verification procedure was separated into stages and the order dependencies were sorted out. Changing independent tasks to run in parallel is the main factor in the speed improvement.

Resource management: Resident processing was minimized, and memory usage and program size were reduced. Lowering the burden on the user environment leads to stability.

Verification: Operation was checked across a variety of environment combinations. A public system cannot specify the user environment, so the scope of verification must be wide.

Design principle: The most important thing in this system is that everyone must be able to participate at the set time. The worst case matters more than the average processing time, and eliminating situations that fail only in certain environments was the priority.

Problems addressed during implementation

• Balancing security and speed: The option of reducing the items verified was ruled out from the start. Time had to be reduced only by reorganizing the order of the steps and their duplication.
• User environments that cannot be controlled: There is no way to know which programs are installed. We reduced assumptions about the environment and confined behavior affected by external factors to the inside of the program.
• Pressure of the deadline: Bidding ends at a set time. When an error occurs, the user has no time to work out the cause. Distinguishing errors in the guidance was as important as the features.
• Verification scope of a public system: A program that works only in certain environments cannot be used. Verification takes a larger share than in an ordinary project.

Characteristics of public system improvement projects

There are three differences from improving a private service.

The user environment cannot be chosen. Recommended specifications can be announced, but they cannot be enforced. Participating in a bid is a company's right, so a situation in which a company cannot participate because of its environment must not arise. This constraint widens both the design and the scope of verification.

The option of cutting features is limited. A private service can secure performance by removing features that are not used. In a public system, procedures required by the regulations cannot be left out at will. A way to do the same work more efficiently has to be found.

The impact of failure falls directly on individual users. A service slowing down briefly and being unable to take part in a bid carry different weight. A single failure can eliminate a company's business opportunity, so the standard for stability is high.

In summary

Safe Bidding 2.0 was a project to improve execution speed and stability while maintaining the level of security.

Reducing the items verified was ruled out from the start. By rearranging the order of the steps and removing duplicate checks, we raised execution speed by 64.3%, and by reducing the resource footprint and environment dependency, we reduced program conflicts by 86.4%.

A public procurement system cannot specify the user environment, and its deadline is fixed. This is why we took as our criteria reducing the worst case rather than the average processing time, and eliminating situations that fail only in certain environments.

6. Project Information

Item	Details
Project name	Safe Bidding 2.0 system build (electronic procurement external control)
Scope of work	Security module improvement and optimization