Clever Engineer

Try out our new Mobile app that help smoothing payment of Events

Version with updated instructions

Join the Tick8 Plus Beta Testing Program!

We’re excited to announce the beta testing program for Tick8 Plus, the cashless event ticketing platform developed by BITS. We seek feedback from passionate users to help us improve the attendee and organizer mobile apps. Testing is currently limited to Android (APK), and your feedback will be invaluable in shaping the final version of our platform.

By joining, you’ll be among the first to experience Tick8 Plus' seamless ticket purchasing, NFC-based in-event transactions(excluded from this initial test), and more! Your honest and logical feedback will help us deliver the best possible product.

How It Works:

Sign Up: We collect your name and email to have a record of all testers.
Anonymous Feedback: To ensure feedback remains unbiased, it will be stored separately from your details, keeping it anonymous.
If you’re interested in being part of our journey and providing valuable insights, please visit our beta program page below:

👉 Join the Tick8 Plus Beta Program (https://www.tick8plus.com/ -program)

We look forward to your participation and thank you for helping us make Tick8 Plus better!

Something to note:
In the attendee app, currently, all payments are in the demo stage, so there no actual deduction will be made.

For stripe payment, you can use the following test details
Card number:
424242424242424242 - expiry:
04/26 | cvv: 424

MTN Momo: any valid 10 digit (0880112233)

Wallet: To use the wallet method as payment, you need to firstly access the wallet screen and top up your wallet using mtn momo (0880112233). Then, you can test the wallet payment feature...

For organizer: The available amount to withdraw will only show after your event has ended. Once your available amount to withdraw is available, you can withdraw using MTN Momo(only for now)Try this new platform

𝐈𝐧 𝐬𝐲𝐬𝐭𝐞𝐦 𝐝𝐞𝐬𝐢𝐠𝐧 𝐈𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬 𝐲𝐨𝐮 𝐰𝐢𝐥𝐥 𝐛𝐞 𝐚𝐬𝐤 𝐭𝐡𝐢𝐬 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧 𝐭𝐨 𝐝𝐞𝐬𝐢𝐠𝐧 𝐚 𝐫𝐚𝐭𝐞 𝐥𝐢𝐦𝐢𝐭𝐞𝐫

A rate limiter serves as a throttle for API endpoints, defining the allowable frequency of API calls within a specified time interval.

𝑊ℎ𝑦 𝑖𝑠 𝑎 𝑟𝑎𝑡𝑒 𝑙𝑖𝑚𝑖𝑡𝑒𝑟 𝑐𝑟𝑢𝑐𝑖𝑎𝑙?

It safeguards against potential DOS attacks on APIs and, additionally,

It also curtails costs by processing only those requests that need to be executed within a designated time frame.

When crafting a rate limiter, it's crucial to weigh where to implement it—whether on the client side, server side, or within middleware. The choice depends entirely on the specific problem you are addressing. But the recommend best place is the server

Here are various types of rate limiter algorithms to consider:

𝐓𝐨𝐤𝐞𝐧 𝐁𝐮𝐜𝐤𝐞𝐭 𝐀𝐥𝐠𝐨𝐫𝐢𝐭𝐡𝐦
𝐋𝐞𝐚𝐤𝐲 𝐁𝐮𝐜𝐤𝐞𝐭 𝐀𝐥𝐠𝐨𝐫𝐢𝐭𝐡𝐦
𝐅𝐢𝐱𝐞𝐝 𝐖𝐢𝐧𝐝𝐨𝐰 𝐂𝐨𝐮𝐧𝐭𝐞𝐫
𝐒𝐥𝐢𝐝𝐢𝐧𝐠 𝐖𝐢𝐧𝐝𝐨𝐰 𝐂𝐨𝐮𝐧𝐭𝐞𝐫
𝐃𝐢𝐬𝐭𝐫𝐢𝐛𝐮𝐭𝐞𝐝 𝐑𝐚𝐭𝐞 𝐋𝐢𝐦𝐢𝐭𝐢𝐧𝐠

𝗧𝗼𝗸𝗲𝗻 𝗕𝘂𝗰𝗸𝗲𝘁 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺

Maintain a bucket with tokens, each representing the right to make an API call.
Tokens are added to the bucket at a fixed rate.
When an API call is made, a token is consumed from the bucket.
If the bucket is empty, further API calls are delayed until tokens are replenished.

𝗟𝗲𝗮𝗸𝘆 𝗕𝘂𝗰𝗸𝗲𝘁 𝗔𝗹𝗴𝗼𝗿𝗶𝘁𝗵𝗺

Conceptually, requests "leak" into a bucket at a fixed rate.
When a request arrives, it is placed in the bucket.
If the bucket is full, excess requests are discarded or delayed.
Requests are processed at a constant rate, preventing bursts of traffic.

𝗙𝗶𝘅 𝘄𝗶𝗻𝗱𝗼𝘄

Maintain a counter for each fixed time window.
Increment the counter for each API call within the window.
Reset the counter at the end of the window.
Limit the total count within the window to control the rate.

𝗦𝗹𝗶𝗱𝗶𝗻𝗴 𝗪𝗶𝗻𝗱𝗼𝘄 𝗖𝗼𝘂𝗻𝘁𝗲𝗿

Similar to the fixed window counter, but the time window "slides" continuously.
Track the count of API calls within the most recent time interval.
Enforce a limit on the total count within the sliding window.

𝗗𝗶𝘀𝘁𝗿𝗶𝗯𝘂𝘁𝗲𝗱 𝗥𝗮𝘁𝗲 𝗟𝗶𝗺𝗶𝘁𝗶𝗻𝗴

Use multiple rate limiters distributed across different components or servers.
Centralized coordination or distributed algorithms ensure a global rate limit is maintained.
Effective for large-scale systems to prevent overloads and ensure fair resource allocation.

Each algorithm provides a different approach to controlling the rate of API requests, allowing system designers to choose based on specific requirements and characteristics of their applications.

Follow Clever Engineer for more quality tech knowledge