In times of uncertainty–driven by an acquisition, changing consumer demand, or a global pandemic–even the smallest software design problems can make the difference between a fragile enterprise and a fit one.
Below, I outline four real-world scenarios that bring today’s most common software design challenges to life. If your organization has been around for five years or more, chances are you’re dealing with an application that suffers from at least one of these. You’re not alone. The good news is, the solution to every one of these challenges is unexpectedly simple, and Polaris can help.
1. Tight Coupling
Let’s assume your customer-facing website allows users to register new accounts. A customer registers and a record is written to the user table. Simple, easy, and clean–right?
Over the years, though, your website has picked up some new responsibilities. Today, it also interfaces with reporting software to generate user reports. It sends new user information to your CRM via an ancient API. It sends an SMS to your head of marketing when a user registers on the first day of the month. And it logs user registration data to an external auditing database. This is tight coupling, in a nutshell.
Suddenly, no developer wants to touch your website because it has a huge number of external dependencies. No single person knows how all of those dependencies work together, and the team that owns the website has to deal with a myriad of issues without a source of truth to guide them.
Now let’s imagine that you’ve got a system that produces data throughout the day. You have another system which needs to process that data when it is available, to do some application-specific magic to it.
The first solution to this problem, because it often seems the most obvious is: polling! Poll the database over and over to check to see if new data is available. Poll a file share for new files and take action when files are detected. Poll an email inbox for new messages.
Polling comes with its own set of problems, however. It can be processor intensive and incredibly inefficient, especially if you’re polling over and over only to get back the same, unchanged state.
3. Unreliable Messaging
Your invoice processing system is the cash register of your organization. When an invoice fails to process, people don’t get paid.
Yet week after week, one or more invoices fail simply because they get processed when the database is offline for maintenance. The next day, Ted in Accounts Receivable has to manually load each failed invoice and wait for them to be processed later that night. When your app suffers from unreliable messaging, it can slow your team down and keep you from streamlining mission-critical business processes.
4. Nonreactive UX
Your website has tons of data available to present to your users. When any of that data changes, you’d love for a given user to be able to see those changes reflected immediately. Instead, your current model requires all of that user’s data to be loaded when they login, then it remains static until they login again.
Nonreactive UX is one of those software design problems that can mean the difference between an experience that keeps up with your users, and one that’s riddled with frustration for them.
A Straightforward Solution: Event-Driven Architecture
It might surprise you to learn that each of these scenarios and software design problems can be made better by moving from a request-driven architecture to an event-driven one. Sound scary? It’s not! In fact, Azure Service Bus makes it relatively simple to move to a pub/sub model and quickly start leveraging the power of eventing.
If you lack the time and HR resources to make the move, look no further. At Polaris Solutions, we offer custom software solutions on demand, so you can create new revenue streams or roll out enhanced, innovative services and experiences for your customers and team. Reach out to learn more about how we can use Azure Service Bus to achieve your priorities.
Stay tuned for an upcoming post, where I’ll dig deeper into how to take the pain points above and turn them into wins using an event-driven approach.
Back to Blog